> ModificationForbidden is resumable like a Warning, and unlike most Errors.  Perhaps it should be a Warning.


-1. :-) Warnings are Notifications, and Notifications are characterized by their property not to have any side-effects on the core operation unless handled by any caller. (A second type of Notification is used for requesting some value that can be answered by any handler, but the overall effect is the same.) See Notification >> #defaultAction and its class comment.

If a ModificationForbidden exception is resumed, the object keeps unmodified, so this is a kinda dangerous resumption. That's also why the defaultAction of a MF is not to resume the execution but to raise an UnhandledError instead, which, IMHO, is the (only) right way to handle the event that a low-level operation could not be executed as you would have expected.


I would never expect the following to evaluate to 0 because any far-away caller could resume every possible MF:

#(0) at: 1 put: 1; first

How could you write reliable code if you had to make such assumptions? I believe that this would lead us to crazy shambles where you had to question every obvious fact.


Warnings say: You shouldn't do this, or maybe you don't actually want to do this, but it is possible to continue doing so, so we won't stop you from doing so until you decide otherwise.

Errors say: You can't do this, and we won't permit that attempt, so you can either decide to actively ignore this error and skip to the next statement, or we'll blow up the execution (and almost ever open a Debugger).

At least this is what I could learn from Squeak's exception framework until now. As always, I'm open for new perspectives :-)

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Chris Muller <asqueaker at gmail.com>
Gesendet: Freitag, 10. April 2020 00:15 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Why is ModificationForbidden not an Error?

ModificationForbidden is resumable like a Warning, and unlike most Errors.  Perhaps it should be a Warning.

Proper signaling and handling are independent of each other.  Please evaluate your decision from the handling side too -- whether it'd be better for TestRunner's handling to include ModificationForbidden.

 - Chris

On Thu, Apr 9, 2020 at 12:44 PM Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> wrote:

Thanks for the fast feedback, I am going to commit this to the Inbox!

<http://www.hpi.de/>

> Making it an error might also make smalltalkCI (through SUnit) catch it to continue. Failing the tests rather than halting the run.

Exactly, that was also my original motivation to ask this question :-)

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com<mailto:eliot.miranda at gmail.com>>
Gesendet: Donnerstag, 9. April 2020 17:03:59
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Why is ModificationForbidden not an Error?

Hi Christoph,


On Apr 9, 2020, at 7:01 AM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> wrote:



Hi all,


please take a short look at this behavior:


TestRunner openForSuite: MorphicUIManagerTest suite. "Run Selected"

<http://www.hpi.de/>

At the moment (#19541), a bug in FileList2 class >> #endingSpecs (which I'm going to fix ASAP) breaks the test #testShowAllBinParts. But because ModificationForbidden is not an Error, it is not caught by the TestRunner so the whole suite run blows up, too.
I could make another example by triggering a ModificationForbidden in a #drawOn: method to destroy the whole image, too.
(Morph newSubclass compile: 'drawOn: x #(1) at: 1 put: 2'; new) openInHand)

So my question is: Why doesn't ModificationForbidden derive from Error? Isn't it actually an error? Similar illegal operations such as "#() at: 0" or "{} at: 1 put: #foo" raise some kind of Error, too. Everything I learned so far about Squeak's exception framework tells me that you should have a very good reason if you design an exception neither to derive from Error, nor from Notification. At the moment, we only do have 9 exceptions (bad pun ...) to this rule (and I'm not even sure whether MCNoChangesException couldn't be a notification, and Abort does not even have senders in the Trunk).
I'd be happy if you could give me some pointers on why ModificationForbidden does not follow this rule. How can we deal with this in order to fix the bugs/unexpected behaviors mentioned above?

I think this is an oversight in my part.  I agree that ModificationForbidden is an error.  I took the code from Pharo and didn’t notice ModificationForbidden was a Notification.

Please feel free to make it an Error.


Possibly related stuff:

  *   http://forum.world.st/Squeak-s-AssertionFailure-vs-SUnit-s-TestFailure-td5106818.html
  *   http://forum.world.st/The-Trunk-Kernel-eem-1294-mcz-td5112196.html
  *   http://forum.world.st/The-Trunk-Kernel-eem-1317-mcz-tp5113273p5113433.html

Best,
Christoph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200409/958c567c/attachment-0001.html>