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

[Andres Valloud]

> 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.