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

[Andres Valloud]

If it were up to me, I'd rather send #return: because then what is 
intended is explicit.  Usually exception frameworks interpret the value 
of the handler block as what is intended to return, so I can see some 
would argue against writing that unnecessary code.  However, that means 
one has to be aware of that when writing complex handler blocks, because 
code rearrangement means potentially inserting ex return: ... where it 
was omitted.  Again, just my opinion, but since most of my time is not 
going into writing code, I do not mind writing a bit more if I see that 
facilitates reading and changing later (which is where most of the time 
is spent).

By breakpoint, yes, I meant that (or even the VW breakpoints, they seem 
similar to what you describe in VA) --- or even inserting #halt if no 
other method is available.

On 10/14/19 14:02, Chris Muller wrote:
> 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 <mailto: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 <mailto:Cuis-dev at lists.cuis.st>
>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>