<div dir="ltr">Hi Andres,<div> I appreciate your explanation on how the exception mechanism works, but it was not really necessary 😉<div> I see that we do not agree on this... </div><div> I'd like to comment on some things you said: </div></div><div><br></div><div>"You have no idea what subclasses of Error exist in the system when such</div>assertions / handlers block run. You have no idea what code somebody<br>put in defaultAction."<div><br></div><div> The defaultAction does not also know the subclasses of Error when it was written. </div><div><br></div><div>"But now on: Error do: [...] breaks that functionality because explicit</div>handlers stop default handlers from running"<div><br></div><div> 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. </div><div> 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 "</div><div><br></div><div>"What you are suggesting with that on: Error do: [...] business is to<br>always stop looking for handlers between steps 1 and 2, and to<br>substitute steps 2-5 with a universal handler that somehow will know how<br>to handle everything."</div><div><br></div><div> No, I've never suggested that.</div><div><br></div><div>Have a nice day,</div><div>Hernan.</div><div><br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 15, 2024 at 10:11 PM Andres Valloud <<a href="mailto:ten@smallinteger.com">ten@smallinteger.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Moreover, I'm sure you know this, but let's make sure exception handling <br>
is clear. Here's how the handler of an exception is chosen.<br>
<br>
1. Find an on:do: for the exception in question. If there is one, <br>
evaluate the associated block.<br>
<br>
2. No on:do: handler. Run the default handler of the exception in <br>
question by sending defaultAction to the exception.<br>
<br>
3. Let's say you have no refined defaultAction, now you get the default <br>
defaultAction, which for errors is typically to resignal as an unhandled <br>
exception.<br>
<br>
4. Ok, start over. Find an on:do: for the unhandled exception. If <br>
there is one, evaluate the block.<br>
<br>
5. No on:do: handler for the unhandled exception. Run the default <br>
handler of the unhandled exception. In most cases, this means "stop, <br>
open a debugger".<br>
<br>
(Of course all steps can also send pass, retry, return, return:, <br>
resignalAs:, etc)<br>
<br>
<br>
What you are suggesting with that on: Error do: [...] business is to <br>
always stop looking for handlers between steps 1 and 2, and to <br>
substitute steps 2-5 with a universal handler that somehow will know how <br>
to handle everything. Obviously this is not going to work. What <br>
happens if somebody added critical code to defaultAction at step 3? <br>
Well, you just broke their code.<br>
<br>
This is why the vast majority of<br>
<br>
on: Error do: [...]<br>
<br>
should be<br>
<br>
on: UnhandledException do: [...]<br>
<br>
instead.<br>
<br>
Andres.<br>
<br>
On 4/15/24 5:52 PM, Andres Valloud via Cuis-dev wrote:<br>
>> If so, I agree with you, that is why you can have a block as a <br>
>> handling condition and that is also why when testing for exceptions <br>
>> there should be an assertion to check that the right assertion was <br>
>> signaled (for example checking the message of the exception).<br>
> <br>
> You say you agree, then immediately reach the same conclusions as before.<br>
> <br>
> 1. No [:ex | ] handler block can substitute for default handlers whose <br>
> job may be to handle the exception in question for you. So, blanket <br>
> assertions like on: Error do: [fail the test] are wrong.<br>
> <br>
> You have no idea what subclasses of Error exist in the system when such <br>
> assertions / handlers block run. You have no idea what code somebody <br>
> put in defaultAction.<br>
> <br>
>> As a rule of thumb, I create new types of exceptions if there is a <br>
>> handling condition for it, if not I reuse existing exception types.<br>
> <br>
> Again, you do not know what code is in defaultAction. Blanket <br>
> interpreting every occurrence of Error as fatal is just wrong.<br>
> <br>
> 2. Consider modeling the well known Unix error EAGAIN as an exception. <br>
> This is an error, so you create e.g. UnixEAGAIN. The default reaction <br>
> to the EAGAIN error is to try the operation again. So, you put in code <br>
> in UnixEAGAIN>>defaultAction to retry, because that's what the manual <br>
> says. You type this handling code only once, because *of course* you do <br>
> not want to copy paste that everywhere with explicit on:do: handlers, <br>
> and that's it.<br>
> <br>
> But now on: Error do: [...] breaks that functionality because explicit <br>
> handlers stop default handlers from running.<br>
> <br>
> There is no way to account for unknown exceptions and default handlers <br>
> that may not have been written yet, or of which you know nothing about.<br>
> <br>
> Andres.<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></strong></span></div><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></strong></span><font face="tahoma, sans-serif" size="2">-4893-2057</font></div><div style="font-size:12.8px"><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" target="_blank">http://www.10Pines.com</a></span></font></span></span></strong></span></div><div style="font-size:12.8px"><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div>