In this case we might want specialized subclasses...

Le sam. 11 avr. 2020 à 03:45, Chris Muller <asqueaker at gmail.com> a écrit :

> 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/20200411/798ea93a/attachment.html>