I think so, because if you try to use it for something else, it'll get
entangled with your application's standard error handling.  Regular apps
have error handling like:

   [ myApp doStuff ] on: Error do: [ : err | myApp logErrorAndNotifyUser ]

and so for the use-case, *Protect CompiledMethod Literals from Accidental
Modification*, inheriting from Error will allow the best backward
compatibility with existing handlers.

But if they want to use ModificationForbidden for a *Write Barrier*,
they'll probably want to extricate it from Error in the handler:

   [ myDbApp doStuff ]
     on: ModificationForbidden
     do:
          [ : forbidden |
          forbidden object beWritableObject.
          forbidden resumptionValue: forbidden retryModificationNoResume.
          forbidden resume: forbidden resumptionValue ]
     on: Error
     do: [ : err | myDbApp logErrorAndNotifyUser ]

But now that I'm handling ModificationForbidden separately, what if I
want *Protect
CompiledMethod Literals from Accidental Modification*, too?  I'm no longer
handling correctly for that, because the handler has to assume they're
signaled in the context of the DB use case and not the Protection use case.

 - Chris

On Fri, Apr 10, 2020 at 12:06 PM tim Rowledge <tim at rowledge.org> wrote:

>
>
> > On 2020-04-09, at 6:55 PM, Chris Muller <asqueaker at gmail.com> wrote:
> >
> > The two main use cases of ModificationForbidden present opposite
> perspectives onto it.
>
> In that case perhaps we actually need two different signals?
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Has an inferiority complex, but not a very good one.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200410/62099e87/attachment.html>