Object>>doesNotUnderstand:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Object>>doesNotUnderstand:

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

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?

Best regards,
Denis



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Martin McClure-2
On 07/27/2010 12:21 PM, Denis Kudriashov wrote:
> Hello,
>
> I found method doesNotUnderstand have very strange implementation
>

[...]

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

It's this way so that in development when you hit a MNU the debugger
opens, you can define the missing method, hit proceed in the debugger,
and it retries the send.

It's not the best implementation for allowing the debugger to be turned
off in production like you're doing.

Regards,

-Martin

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Eliot Miranda-2
In reply to this post by Denis Kudriashov


2010/7/27 Denis Kudriashov <[hidden email]>
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Denis Kudriashov
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 <[hidden email]>


2010/7/27 Denis Kudriashov <[hidden email]>

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Eliot Miranda-2


2010/7/27 Denis Kudriashov <[hidden email]>
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 <[hidden email]>



2010/7/27 Denis Kudriashov <[hidden email]>

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Denis Kudriashov
In reply to this post by Denis Kudriashov
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


28 июля 2010 г. 0:48:18 UTC+4 пользователь dionisiydk <[hidden email]> написал:
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 <[hidden email]>


2010/7/27 Denis Kudriashov <[hidden email]>

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Eliot Miranda-2


2010/7/27 Denis Kudriashov <[hidden email]>
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 <[hidden email]> написал:

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 <[hidden email]>


2010/7/27 Denis Kudriashov <[hidden email]>

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Eliot Miranda-2


2010/7/27 Eliot Miranda <[hidden email]>


2010/7/27 Denis Kudriashov <[hidden email]>
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 <[hidden email]> написал:

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 <[hidden email]>


2010/7/27 Denis Kudriashov <[hidden email]>

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Denis Kudriashov
In reply to this post by Eliot Miranda-2
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.

Thanks, It really work



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Object>>doesNotUnderstand:

Stéphane Ducasse
Denis

I would really like to see/have access to your code because I think that the behavior you want should be in any system so that you can run really headless.

Stef
On Jul 27, 2010, at 10:58 PM, Denis Kudriashov wrote:

> 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.
>
> Thanks, It really work
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project