[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