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> im Auftrag von Eliot Miranda <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> 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/66132ff9/attachment-0001.html>