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.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150117/6fd422d3/attachment.htm