[Cuis-dev] Additional note on exception handler code patterns

Andres Valloud ten at smallinteger.com
Mon Oct 14 00:06:41 PDT 2019


By the way, there is another exception handler block code pattern that 
obstructs debugging.  The problem is with exception handlers that do not 
tell the exception what to do, i.e.:

	[:ex | nil]

Suppose you have something like

	on: SeveralKindsOfError do: [:ex | nil]

and you need to sort out how it fails with only one of said exceptions. 
You can't put a breakpoint in [:ex | nil] because that code is heavily 
used by the system, and you can't breakpoint e.g. #return: for the 
exception you're interested in, e.g.:

	InterestingException>>return: anObject

		self halt.
		^super return: anObject

because the message is not being sent in the first place.  Ok fine you 
modify the code while you're debugging, and now you need to remember 
that some package will look dirty for a while, and you also have to undo 
all those modifications before you post the actual intended changes. 
Anyone that has to debug that code will have to go through those 
motions, now and in the future.

All that extra work goes away by writing

	[:ex | ex return: nil]

instead.

Andres.


More information about the Cuis-dev mailing list