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

[Andres Valloud]

FYI, in 2011 the expert you mentioned gave a presentation in which, 
talking about lost ideas, cites Smalltalk's class level handlers and 
even gives an example that agrees with what I am saying as an example of 
doing things well.  See reference 26 here, starting at slide 30, and 
specifically slide 33 for a default handler that retries the operation 
that failed.

https://www.lirmm.fr/~dony/

On 4/16/24 7:56 AM, Hernán Wilkinson wrote:
> 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 
> <mailto: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 Wilkinson
> Agile 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