[squeak-dev] Why is ModificationForbidden not an Error?

Eliot Miranda eliot.miranda at gmail.com
Wed Apr 22 23:50:21 UTC 2020


Hi All,

On Wed, Apr 22, 2020 at 10:59 AM tim Rowledge <tim at rowledge.org> wrote:

>
>
> > On 2020-04-22, at 3:20 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> >
> > Hi all!
> >
> > So, we make ModificationForbidden a (resumable) Error for now? Is this
> the conclusion?
>

Yes, I hope so :-)


>
> It's a super-low-level error that ought to be handled really really
> closely to where the error was raised. As Eliot mentioned, the VM can't
> know the circumstances and just raises it; the the closest possible handler
> should be in place that *does* know the circumstances. That way Chris gets
> to spot that is it a database issue and handle things properly, including
> likely raising a new error for higher level code.
>

As I've already mentioned what one can do, and the VisualWorks version does
do, for GemStone-style persistence, as add behavior to the exception so one
can specify a per-object response.

So if the exception is unhandled, then before it raises an UnhandledError
it checks an identity dictionary, which maps object to message, and if the
read-only object that was the cause of the error is in the dictionary,
instead the exception performs the message with the object as an argument.
So a database layer can add the objects it is managing to the map in
ModificationForbidden, and mark them as read-only.  Then any and all
attempts at modifying these objects will cause the database man ager to be
notified.

So very simply we can have a pluggable solution that allows different
clients to map the exception into different responses as desired.
So can we please stop wasting time discussing this and get on with
implementing it?  The GemStone folks have understood how to manage
ModificationForbidden for years and the use of it has been in production.
We simply need to catch up.  We're nearly there.

Please don't make me explain this idea once again ;-)

>
>
> Given having a handler really close to the source, perhaps we are better
off keeping it non-resumable and using one of the other approaches to
continuing like #retryUsing: (ExceptionTester>>#simpleRetryUsingTest is the
only example in the clean image) ?

>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: BFM: Branch on Full Moon
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200422/31ace3ae/attachment.html>


More information about the Squeak-dev mailing list