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

Chris Muller asqueaker at gmail.com
Mon Oct 14 14:02:23 PDT 2019


Hi Andres,

I'm really interested in this because I've always wondered if there was
some reason I should use #return: instead of simply letting the last
expression be the resultant value.  In general, I've not used #return:
simply for brevity of code.

By "breakpoint", I assume you're referring to something other than changing
the code and inserting a #halt.  Something like the old VisualAge
breakpoints that replaces the CompiledMethod with one that halts somewhere
on the line where the breakpoint was added, so that, as you said, you won't
make the package dirty just for a quick debug.

Still, I was wondering if the benefit to using #return: is limited to the
use of breakpoints, or if there are any other reasons I should use #return:
in my handler.

Thanks,
  Chris

On Mon, Oct 14, 2019 at 2:06 AM Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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.
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191014/1befaed8/attachment.htm>


More information about the Cuis-dev mailing list