Exception question

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

Exception question

Erlis Vidal
Hi,

I've been reading about the smalltalk exceptions thanks to some suggestions received in this list.

While  reading https://gforge.inria.fr/frs/download.php/26600/PBE2-Exceptions-2010-03-02.pdf (page 9) I found the implementation for Object>>doesNotUnderstand but there is something I don't understand and I'm wondering if someone can help me.

Object»doesNotUnderstand: aMessage

"Handle the fact that there was an attempt to send the given message to the receiver
but the receiver does not understand this message (typically sent from the machine
when a message is sent to the receiver and no method is defined for that selector).
"
MessageNotUnderstood new
message: aMessage;
receiver: self;
signal.
↑ aMessage sentTo: self.


I'm having problem with the line in red. The method is pretty simple, it just create a new MessageNotUnderstood instance and then send the message: and receiver: messages, but it also signal the exception, which I was thinking will finish the method execution, but if that's the case, Why the red line? Why returning anything after signaling the exception?

Regards,
Erlis

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Exception question

Randal L. Schwartz
>>>>> "Erlis" == Erlis Vidal <[hidden email]> writes:

Erlis> I'm having problem with the line in red.

I don't see anything in red.  Please note that many of us read messages
in plain ASCII or unicode, not crappy HTML-pretending-to-be-email.

Erlis>  The method is pretty simple, it
Erlis> just create a new MessageNotUnderstood instance and then send the message:
Erlis> and receiver: messages, but it also *signal *the exception, which I was
Erlis> thinking will finish the method execution, but if that's the case, Why the
Erlis> red line? Why returning anything after signaling the exception?

I think you're referring to the fact that someone can say "resume" even
after the signal has been thrown.  That will return back to *this*
context, and resend the original message.  That's exactly the flow you
want if you want a chance to fix something in a debugger, and then retry
the original request.  The debugger "proceed" will come back to here,
but the original message needs to be resent, probably poking at a new
version of a method (or one of the methods it calls).

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Exception question

Erlis Vidal
Hi Randal,

sorry about using colors, the line in red was the last one, the return

↑ aMessage sentTo: self.


What you said makes things clear, with the "resume" we need that line...

Thanks for the explanation,
Erlis

On Thu, Apr 14, 2011 at 2:52 PM, Randal L. Schwartz <[hidden email]> wrote:
>>>>> "Erlis" == Erlis Vidal <[hidden email]> writes:

Erlis> I'm having problem with the line in red.

I don't see anything in red.  Please note that many of us read messages
in plain ASCII or unicode, not crappy HTML-pretending-to-be-email.

Erlis>  The method is pretty simple, it
Erlis> just create a new MessageNotUnderstood instance and then send the message:
Erlis> and receiver: messages, but it also *signal *the exception, which I was
Erlis> thinking will finish the method execution, but if that's the case, Why the
Erlis> red line? Why returning anything after signaling the exception?

I think you're referring to the fact that someone can say "resume" even
after the signal has been thrown.  That will return back to *this*
context, and resend the original message.  That's exactly the flow you
want if you want a chance to fix something in a debugger, and then retry
the original request.  The debugger "proceed" will come back to here,
but the original message needs to be resent, probably poking at a new
version of a method (or one of the methods it calls).

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - <a href="tel:%2B1%20503%20777%200095" value="+15037770095">+1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners