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