[squeak-dev] The Trunk: System-cmm.694.mcz

Eliot Miranda eliot.miranda at gmail.com
Sun Jan 18 00:59:18 UTC 2015


Hi Chris,

On Jan 17, 2015, at 4:45 PM, Chris Muller <asqueaker at gmail.com> wrote:

> On Sat, Jan 17, 2015 at 4:03 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> Hi,
>> 
>> On Sat, Jan 17, 2015 at 10:35 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> Hi Frank,
>>> 
>>> On Jan 17, 2015, at 3:39 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> 
>>> > On 16 January 2015 at 21:44,  <commits at source.squeak.org> wrote:
>>> >> Chris Muller uploaded a new version of System to project The Trunk:
>>> >> http://source.squeak.org/trunk/System-cmm.694.mcz
>>> >>
>>> >> ==================== Summary ====================
>>> >>
>>> >> Name: System-cmm.694
>>> >> Author: cmm
>>> >> Time: 16 January 2015, 3:44:19.079 pm
>>> >> UUID: e79a2347-2f40-4fec-8f00-f67ecad68491
>>> >> Ancestors: System-dtl.693
>>> >>
>>> >> - #flush stdout and stderr after writing error information to them.
>>> >> - After that, if the exception is resumable (i.e. a Warning), resume it.  Except if its a MessageNotUnderstood -- that is not an error you want to resume in a headless environment.
>>> >
>>> > Why? It's probably a rare use case for a #run: script to catch MNUs to
>>> > do something fancy, I guess? Maybe it's because #run: is usually
>>> > (always?) the top level of the program?
>>> 
>>> One reason is that resuming an MNU simply resends from the diesNotUnderstand: method, so resuming will result in infinite recursion.  I suppose the handler could allow one repeat but that seems arbitrary.  There's nothing to stop one including a resuming MNU handler in the expression if one wants to override the default behaviour.
>>> 
>>> >
>>> > Catching only MNUs seems very specific. Maybe there could be a #run:
>>> > version that says "and here's a function you can use to control which
>>> > exceptions are OK to resume, and which not"?
>>> 
>>> Well there is Notification and Warning but (rightly) MessageNotUnderstood is an Error.  Reporting Notifications and Warnings to the output and continuing, but aborting for other exceptions seems the right thing to do, rather than basing it in resumability, yes?  What am I missing?
>>> 
>>> Whether an exception is resumability or not is to do with whether one can usefully provide a value with which to continue, not to do with the severity of the error.  For example, being able to resume with nil for a permissions violation when opening a file or directory might make it really easy to implement a find(1) like search over directories where some may be unreadable due to permissions.  Being able to resume doesn't make the permissions violation any the less severe, but it dies give us a nice way if handling it, certainly less complex than having to explicitly check for permissions during the traversal.  Likewise, being able to substitute a value for an MNU allows all sorts of conveniences, eg see my code for disassembling methods to bytecode messages.
>>> 
>>> So IMO the system should be reporting Notifications and Warnings and aborting for anything else.
>>> 
>>> >
>>> > frank
>>> 
>>> Eliot (phone)
>> 
>> See the Error handler in SmalltalkImage>>run:
>> 
>>                 on: Error
>>                 do:
>>                         [ : err | err printVerboseOn: FileStream stderr.
>> +                       FileStream stderr flush.
>> +                       (err isResumable and: [ (err isKindOf: MessageNotUnderstood) not ])
>> +                               ifTrue: [ err resume ]
>> +                               ifFalse: [ self haltOrQuit ] ]!
>> -                       self haltOrQuit.
>> -                       err isResumable ifTrue: [ err resume ] ]! 
>> 
>> 
>> IMO, this should read
>> 
>>                on: Error
>>                do:
>>                         [ : err |
>>                          err printVerboseOn: FileStream stderr.
>>                          FileStream stderr flush.
>>                          self haltOrQuit]! 
>> 
>> Resuming is definitely not safe; it could cause the software to attempt something damaging right?  And whatever is caught here is an error, no haltOrWuit is the only valid response, no?  I'm happy to make the change.
> 
> Actually, I think I should put it back to my original code.
> 
>                on: Error
>                do:
>                         [ : err |
>                          err printVerboseOn: FileStream stderr.
>                          FileStream stderr flush.
>                          err isResumable ifTrue: [ self haltOrQuit ] ]! 
> 
> That way, if its headless, it'll exit every time.  If it's headful, the user will have the chance to fix the Error before clicking Proceed in the debugger.

Agreed.  That's good behavior.  But it's entirely non-obvious that that's the effect of
       err isResumable ifTrue: [self haltOrQuit]

So there needs to be a comment immediately before that statement that explains what happens, just

"If we're headless, this will exit every time.  If we're headful, the user will have the chance to fix the Error before clicking Proceed in the debugger."

>> -- 
>> best,
>> Eliot
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150117/4fe9426f/attachment-0001.htm


More information about the Squeak-dev mailing list