bug: prettify error message while h/s is shaking and protocol tries to unlatch

[TamarZanzouri]

Overview

While h/s is shaking try running a protocol with an unlatching command. The command will raise an error as expected but the UI should show a user friendly message?

Steps to reproduce

1. test shaking with the h/s
2. run the following protocol

metadata = {
    'protocolName': 'Heater-shaker test protocol w/ blocking commands',
    'author': 'Opentrons <[email protected]>',
    'apiLevel': '2.12'
}

def run(context):
	# Load Heater-shaker module
	hs_mod = context.load_module("heaterShakerModuleV1", "1")

	# Load adapter + labware on module. Available labware:
	# - opentrons_96_flat_bottom_adapter_nest_wellplate_200ul_flat
	# - opentrons_96_pcr_plate_adapter_nest_wellplate_100ul_pcr_full_skirt
	# - opentrons_96_deepwell_adapter_nest_wellplate_2ml_deep
	# - opentrons_flat_plate_adapter_corning_384_wellplate_112ul_flat
	hs_plate = hs_mod.load_labware("opentrons_96_flat_bottom_adapter_nest_wellplate_200ul_flat")

	# tiprack_300ul = [context.load_labware('opentrons_96_tiprack_300ul', 3)]
	# p20 = context.load_instrument('p300_single', 'right', tip_racks=tiprack_300ul)

	tiprack_10ul = [context.load_labware('opentrons_96_tiprack_300ul', 5)]
	p20 = context.load_instrument('p300_single_gen2', 'right', tip_racks=tiprack_10ul)

	reservoir = context.load_labware('agilent_1_reservoir_290ml', 4)

	hs_mod.open_labware_latch()
	
	hs_mod.set_and_wait_for_temperature(celsius=80)  # Waits until H/S is at 80C

	p20.pick_up_tip()
	p20.aspirate(10, reservoir['A1'])
	p20.dispense(10, hs_plate['A1'])
	p20.drop_tip()

	hs_mod.close_labware_latch()
	hs_mod.set_and_wait_for_shake_speed(rpm=500)	# Waits until H/S has reached 500rpm speed

	context.delay(minutes=1)

	hs_mod.deactivate_shaker()
	hs_mod.deactivate_heater()

this will result with the following error:

Expected behavior

User friendly error message

[SyntaxColoring]

In my opinion, this is mostly expected behavior.

Breaking the error message down:

• ExceptionInProtocolError
  • I think this is probably unnecessary noise; this doesn't have to be displayed to the user.
  • Implementation-wise: I'm not sure exactly how these errors propagate. But if we wanted to strip this out, I could imagine that change happening on the server side, or the app side, or a combination of both.
• CannotPerformModuleAction
  • This looks like the Python exception type that got raised out of the Python Protocol API and into the user's Python script.
  • I strongly feel that it's correct for this to be shown to the user. In Python development in general, when uncaught exceptions are shown to the developer, they normally include this exception type. In our case, the protocol author is the Python developer, so the protocol author needs to see this.
  • In the general case, this part of the string conveys meaningful contextual information that we can't strip out without making the rest of the message more confusing. Try causing a KeyError and see what happens when you remove the string KeyError, for example.
• [Line 26]
  • This is the line in the user's Python protocol where the exception propagated out from, and is important to keep.
• Cannot open labware latch while module is shaking.
  • This is obviously meaningful and is important to keep.

If we want to change the current behavior, I think we need to further specify how these error messages should look.