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

[Andres Valloud]

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.