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. > > 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
