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

Jakob Reschke forums.jakob at resfarm.de
Sat Apr 25 08:06:10 UTC 2020


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?


More information about the Squeak-dev mailing list