2010/7/27 Eliot Miranda <[email protected]> > > > 2010/7/27 Denis Kudriashov <[email protected]> > >> 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. >> >> >> This all work correct with ProtoObject implementation >> >> ProtoObject>>doesNotUnderstand: aMessage >> >> ^ MessageNotUnderstood new >> message: aMessage; >> receiver: self; >> signal >> > > Right, but you can't redefine and continue. The Object implementation does > both. It used to only allow redefinition, not catching. >
I mean the Object implementation used to not allow catching and proceeding, only catching and aborting. cheers Eliot > >> >> 28 июля 2010 г. 0:48:18 UTC+4 пользователь dionisiydk < >> [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. >>> >>> 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
