[Cuis-dev] Enhancement proposal: Fail test when no assertion ran

[Hernán Wilkinson]

Hi Andres,
 I appreciate your explanation on how the exception mechanism works, but it
was not really necessary 😉
 I see that we do not agree on this...
 I'd like to comment on some things you said:

"You have no idea what subclasses of Error exist in the system when such
assertions / handlers block run.  You have no idea what code somebody
put in defaultAction."

 The defaultAction does not also know the subclasses of Error when it was
written.

"But now on: Error do: [...] breaks that functionality because explicit
handlers stop default handlers from running"

 I think we have a different understanding of what defaultAction is. As I
understand it, it is a handler that is run if no other handler is found.
That is how Christophe Dony, an exceptions researcher and expert, explains
them also in the many papers he wrote.
 So, based on that definition it is not a good idea to put in the default
action handling code that should always be executed. It is how you
explained above as step 2: 2.  "No on:do: handler.  Run the default handler
"

"What you are suggesting with that on: Error do: [...] business is to
always stop looking for handlers between steps 1 and 2, and to
substitute steps 2-5 with a universal handler that somehow will know how
to handle everything."

 No, I've never suggested that.

Have a nice day,
Hernan.



On Mon, Apr 15, 2024 at 10:11 PM Andres Valloud <ten at smallinteger.com>
wrote:

> Moreover, I'm sure you know this, but let's make sure exception handling
> is clear.  Here's how the handler of an exception is chosen.
>
> 1.  Find an on:do: for the exception in question.  If there is one,
> evaluate the associated block.
>
> 2.  No on:do: handler.  Run the default handler of the exception in
> question by sending defaultAction to the exception.
>
> 3.  Let's say you have no refined defaultAction, now you get the default
> defaultAction, which for errors is typically to resignal as an unhandled
> exception.
>
> 4.  Ok, start over.  Find an on:do: for the unhandled exception.  If
> there is one, evaluate the block.
>
> 5.  No on:do: handler for the unhandled exception.  Run the default
> handler of the unhandled exception.  In most cases, this means "stop,
> open a debugger".
>
> (Of course all steps can also send pass, retry, return, return:,
> resignalAs:, etc)
>
>
> What you are suggesting with that on: Error do: [...] business is to
> always stop looking for handlers between steps 1 and 2, and to
> substitute steps 2-5 with a universal handler that somehow will know how
> to handle everything.  Obviously this is not going to work.  What
> happens if somebody added critical code to defaultAction at step 3?
> Well, you just broke their code.
>
> This is why the vast majority of
>
>         on: Error do: [...]
>
> should be
>
>         on: UnhandledException do: [...]
>
> instead.
>
> Andres.
>
> On 4/15/24 5:52 PM, Andres Valloud via Cuis-dev wrote:
> >> If so, I agree with you, that is why you can have a block as a
> >> handling condition and that is also why when testing for exceptions
> >> there should be an assertion to check that the right assertion was
> >> signaled (for example checking the message of the exception).
> >
> > You say you agree, then immediately reach the same conclusions as before.
> >
> > 1.  No [:ex | ] handler block can substitute for default handlers whose
> > job may be to handle the exception in question for you.  So, blanket
> > assertions like on: Error do: [fail the test] are wrong.
> >
> > You have no idea what subclasses of Error exist in the system when such
> > assertions / handlers block run.  You have no idea what code somebody
> > put in defaultAction.
> >
> >> As a rule of thumb, I create new types of exceptions if there is a
> >> handling condition for it, if not I reuse existing exception types.
> >
> > Again, you do not know what code is in defaultAction.  Blanket
> > interpreting every occurrence of Error as fatal is just wrong.
> >
> > 2.  Consider modeling the well known Unix error EAGAIN as an exception.
> > This is an error, so you create e.g. UnixEAGAIN.  The default reaction
> > to the EAGAIN error is to try the operation again.  So, you put in code
> > in UnixEAGAIN>>defaultAction to retry, because that's what the manual
> > says.  You type this handling code only once, because *of course* you do
> > not want to copy paste that everywhere with explicit on:do: handlers,
> > and that's it.
> >
> > But now on: Error do: [...] breaks that functionality because explicit
> > handlers stop default handlers from running.
> >
> > There is no way to account for unknown exceptions and default handlers
> > that may not have been written yet, or of which you know nothing about.
> >
> > Andres.
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240416/b808f4b9/attachment-0001.htm>