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

Chris Muller asqueaker at gmail.com
Thu Apr 9 22:15:48 UTC 2020


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


More information about the Squeak-dev mailing list