[squeak-dev] Why is ModificationForbidden not an Error?
Chris Muller
asqueaker at gmail.com
Sat Apr 11 01:44:22 UTC 2020
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>
More information about the Squeak-dev
mailing list
|