Hi Christoph,

I having trouble figuring out whether your points are primarily about
semantics or mechanics..


> > ModificationForbidden is resumable like a Warning, and unlike most
> Errors.  Perhaps it should be a Warning.
>
> -1. :-) Warnings are Notifications,
>
As are Errors.  Right?

> and Notifications are characterized by their property not to have any
> side-effects on the core operation unless handled by any caller.
>
Mmmm, I'm not sure what point you're making here.  Mechanically, they're
all basically the same.  See?

     Notification signal. 'resumed'.         "resumed"
     Warning signal.  'resumed'.             "(click Proceed) resumed"
     Error signal. 'resumed'                    "(click Proceed) resumed"

The fact that Errors can be resumed is a flat out bug, IMO, but they can...

If a ModificationForbidden exception is resumed, the object
> keeps unmodified, so this is a kinda dangerous resumption.
>
"Dangerous" how so?  There's no escaping that ModificationForbidden
introduces new complexity if one isn't aware of it and how it works --
whether they use it or not, even -- could be in for some unexpected
surprises in any case..


> That's also why the defaultAction of a MF is not to resume the execution
> but to raise an UnhandledError instead, which, IMHO, is the (only) right
> way to handle the event that a low-level operation could not be executed as you
> would have expected.
>
And exactly how a Warning behaves...

    Warning signal    "unhandled, debugger appears"
    Notification signal    "unhandled, debugger does not appear"
    [ Warning signal ] on: Warning do: [ : warn | warn resume ]
"handled, debugger does not appear"

In every mechanical way so far, we've seen that Warning is closer to Error
than it is to Notification.

I would never expect the following to evaluate to 0 because any far-away
> caller could resume every possible MF:
>
> #(0) at: 1 put: 1; first
>
>
Which has no bearing on whether its categorized as a Warning or Error...


> How could you write reliable code if you had to make such assumptions? I
> believe that this would lead us to crazy shambles where you had to question
> every obvious fact
>

I'm sorry Christoph.  I must've missed your point.  MF needs to be able to
be resumed.  Squeak allows any Error to be resumed, but this fails your
semantic definition, below...


> Warnings say: You shouldn't do this, or maybe you don't actually want to
> do this, but it is possible to continue doing so, so we won't stop you from
> doing so until you decide otherwise.
>
Which is EXACTLY what ModificationForbidden is..!


> Errors say: You can't do this, and we won't permit that attempt, so you
> can either decide to actively ignore this error and skip to the next
> statement, or we'll blow up the execution (and almost ever open a Debugger).
>
And why it's precisely wrong for ModificationForbidden.  See above.  If you
"can't do this", why would you want to allow it to be resumed?   This is
why only the most exceptional Errors are declared resumable (even though
it's functionally meaningless, just "documentation").  The vast majority of
Errors are not resumable.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200409/2448c582/attachment.html>