I finally got around to read Marcel's changeset and the code that
signals ModificationForbidden. Now I see that resuming the
ModificationForbidden means to skip the modification and proceed with
the code ahead, not to do the modification despite the read-only state
as I assumed. Sorry.

Let me check my understanding. If there is a forbidden modification,
the only way to abort an operation via object handlers is to do a
non-local return eventually (handler is a block or signals another
exception). Because the defaultAction implies that the
ModificationForbidden exception will be resumed and you can only
control the resumption value, unless there is a non-local return
eventually. Is that correct? Then I'm thinking one would rather choose
to handle ModificationForbidden conventionally with on:do: if one
wishes to abort something. And use object handlers only for use cases
where you can actually do something about it.

In that case I'm wondering how an object database is actually going to
proceed from there. Copy, modify, record, become:, let resume? If the
answer is too long, just tell me I would have to read it up in the
literature. ;-)

Am Sa., 25. Apr. 2020 um 10:06 Uhr schrieb Jakob Reschke
<forums.jakob at resfarm.de>:
>
> Am Fr., 24. Apr. 2020 um 23:56 Uhr schrieb Chris Muller <asqueaker at gmail.com>:
> >>
> >> The fact that there is a helpful default handler for an exception does not (should not!) mean you can't catch it and do something more to your liking
> >
> >
> > Only if you control the code.  For Magma-like transparency, it must be able to operate on oblivious objects which have ZERO knowledge of any database or handlers.  Cmd+s in an Inspector should be picked up and saved in the next DB commit, unless it's a CM-literal, in which case it should error immediately...
> >
>
> Hmm for this particular case I don't see the issue. Modification
> through an inspector will create references to other objects, so to
> run into ModificationForbidden here, you would have to modify a
> composite literal object, which could only be an Array if I am not
> mistaken. The elements of literal arrays are literals themselves (not
> in the CompiledMethod-sense, but they are all immutable now, right?
> think of nested arrays). So when you press Cmd+s, you will immediately
> get the exception, before anything changes in the object. So the
> database would not be affected by the error or the modification
> attempt, right?
>
> Or it would proceed immediately because it was registered so in the
> object-specific handler supplied via the methods in Marcel's
> changeset. Then things get modified and so they would be in the
> database. Do you mean the exception could arise again in the database
> code?