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

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Thu Apr 9 14:01:09 UTC 2020


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?

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/f8c127de/attachment.html>


More information about the Squeak-dev mailing list