2010/7/27 Denis Kudriashov <[email protected]> > I think that the bug is that you haven't modified the system to quit on an >> UnhandledException. i.e. in a headless context control should never get >> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >> is not caught. How should one continue after an unhandled error? >> > > With my approach I have "null object message eating" behavior. And when any > unhandled errors raised in system user will see nothing. Only log file will > contain it. >
In either case control should not return to the point of error. If you want to log errors and then continue you need to continue from some well-defined point, not merely return control to the point of error. So if your approach is to catch and log errors, after logging you need to transfer control back to some starting point, e.g. by throwing some ResumeExecution exception. HTH Eliot > 2010/7/28 Eliot Miranda <[email protected]> > > >> >> 2010/7/27 Denis Kudriashov <[email protected]> >> >> Hello, >>> >>> I found method doesNotUnderstand have very strange implementation >>> >>> Object>>doesNotUnderstand: aMessage >>> | exception resumeValue | >>> (exception := MessageNotUnderstood new) >>> message: aMessage; >>> receiver: self. >>> resumeValue := exception signal. >>> ^exception reachedDefaultHandler >>> ifTrue: [aMessage sentTo: self] >>> ifFalse: [resumeValue] >>> >>> When Error has no handlers #defaultAction is executed. For >>> MessageNotUnderstood #defaultAction is UnhandledError signal. And for >>> UnhandledError #defaultAction is opening debugger. >>> If you change it to do nothing (^self) you get infinite loop on any >>> MessageNotUnderstood signal. >>> It is because "ifTrue" branch executed in doesNotUnderstood method and >>> message resend to receiver. >>> >>> Why method implemented such way? Why it is differ from ProtoObject >>> implementation. I think It's bug implementation. >>> >> >> This is intentional. Martin's reply is one half of the issue, that you >> want to be able to proceed after defining a method in the debugger. The >> otehr half is that you want to be able to catch doesNotUnderstand: in an >> exception handler and proceed with a result, e.g. >> >> [nil zork] >> on: MessageNotUnderstood >> do: [:ex| >> ex message selector == #zork ifTrue: >> [ex resume: #ok]. >> ex pass] >> >> evaluates to #ok. >> >> >>> >>> I found this problem when I try implement stuff to turn off openning >>> debugger on unhandled error (and write it to log) >>> >>> UnhandledError>>defaultAction >>> "The current computation is terminated. The cause of the error should >>> be logged or reported to the user. If the program is operating in an >>> interactive debugging environment the computation should be suspended and >>> the debugger activated." >>> ^ToolSet debugError: exception. >>> >>> ToolSet class>>debugError: anError >>> "Handle an otherwise unhandled error" >>> self default ifNil:[ | ctx | >>> Smalltalk >>> logError: anError description >>> inContext: (ctx := anError signalerContext) >>> to: 'PharoDebug.log'. >>> self inform: (anError description, String cr, ctx shortStack). >>> ^anError return]. >>> ^self default debugError: anError >>> >>> I just implement subclass of StandartToolSet with empty method >>> #debugError:. Then I do "ToolSet default: MyToolSet". And now unhandled >>> errors raise infinit loop and never return. >>> >>> I fix that by: >>> >>> MyToolSet>>debugError: anError >>> anError class = MessageNotUnderstand ifTrue: [anError >>> reachedDefaultHandler: true]. >>> >>> I think this is hack. But it is work. No errors show to user.And all work >>> good. >>> >>> What do you think? >>> >> >> I think that the bug is that you haven't modified the system to quit on an >> UnhandledException. i.e. in a headless context control should never get >> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >> is not caught. How should one continue after an unhandled error? >> >> HTH >> Eliot >> >> >>> Best regards, >>> Denis >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
