Hi Chris,


> On Apr 9, 2020, at 3:16 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> 
> ModificationForbidden is resumable like a Warning, and unlike most Errors.  Perhaps it should be a Warning.

One can override isResumable. There’s no invariant that’s a subclass of Error can’t be resumable.  IMO many more Error subclasses that aren’t should be isResumable.


> 
> 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!
>> 
>> 
>> > 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"
>>> 
>>> 
>>> 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/4d62b0a7/attachment.html>