After further thought, I think you're right that it shouldn't inherit from
Warning, because it could get accidentally resumed unintentionally by some
high-level handler like SmalltalkImage>>#run:.

The two main use cases of ModificationForbidden present opposite
perspectives onto it.  For "protection from accidentally modifying a
literal in a CompiledMethod", I understand the inclination to make it an
Error.  However, for the context of db handling, [#markDirty + #resume] is
normal processing, not an "error", and not even exceptional, either, so
perhaps this is just a semantic irritation sensitivity on my part.. sorry.
 Inheriting from Error is probably the most convenient way to preserve the
CompiledMethod protection use case.  Though, I think it's worth
considering sprinkling some handlers of ModificationForbidden as an
alternative.

 - Chris

On Thu, Apr 9, 2020 at 7:18 PM Chris Muller <ma.chris.m at gmail.com> wrote:

> 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/3852056a/attachment.html>