[Glass] Problem with UncontinuableError
Locked
[Glass] Problem with UncontinuableError
 
|
Hi guys, At some place in code, I am storing exceptions when they happen inside a collection. Basically I have a #on:do: and I store the error in a collection. And then I do something (printing basically).
I have a strange behavior in GemStone in comparison to Pharo. In Pharo, I would get the original normal print string of the real exception that happened. In GemStone, instead of getting the original exception I get this:
Any idea what is happening?
Thanks in advance, Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Problem with UncontinuableError
|
|
What message are you sending to trigger the exception and what does the stack look like? Dale On Mon, Mar 10, 2014 at 7:40 AM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Problem with UncontinuableError
|
|
On Mon, Mar 10, 2014 at 1:33 PM, Dale Henrichs <[hidden email]> wrote:
I have seen this in errors I explicitly send this way: Error signal: 'blah blah' Or in things like a zero divide.
What I have reproducible now is a zero divide now. The code looks something like: [ self somethingThatTriggersAZeroDivide. ] on: Error
do: [ :err | | errString | [ stream notNil ifTrue: [ stream nextPutAll: err printString; crlf ] ]
on: Error do: [ :er2 | self halt ]. errString := err printString. obs do: [ :observer | observer erredAction: action on: port with: errString ].
stream notNil ifTrue: [ stream close ]. ^ port ].
so when I get the printString inside the closure...the exception I am getting is a: a UncontinuableError occurred (error 6011), Execution cannot be continued, 'Exception has already been signaled'
However, if I run from a workspace: [ 0 / 0 ] on: Error do: [:ex | ex inspect] it works correct, I do get the ZeroDivide.... any idea? Thanks,
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Problem with UncontinuableError
|
|
Mariano, I guess I am looking for the stack that you get when with the UncontinuableError ... I am looking for the exact message send that causes the UncontinuableError to be signalled ... a complete stack would be nice ....
The fact that you are getting an 'Exception has already been signaled' implies that somewhere in the printString execution the exception (or another) exception is getting signalled ...
Having a full stack of the actual error should provide enough information to help me make progress ...
Dale On Mon, Mar 10, 2014 at 3:01 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Problem with UncontinuableError
Administrator
|
In reply to this post by Mariano Martinez Peck
Mariano, It may well be the ^port in the exception handler is causing this. Try using err return: port as the last line of the handler block. That will cause the block protected by the #on:do: to yield the value passed to #return:. If you have more code in the method after this, you will need to dance a little more to know you need to return from the method. This is just a guess, as ^port should be an acceptable way to finish the exception handler, too. But one can imagine that it isn't as well supported as a "normal" end of block, or a specifically handled exception. |
Re: [Glass] Problem with UncontinuableError
|
|
Hi guys, Richard, the none local return was a good shoot. However, I tried it and still same problem. After Dale's comment, I start to debug a bit more and more. Finally, I found out my code was storing the signaled exception and then at a parent handler it was signaling again, which causes the UncontinuableError.
To reproduce the problem, consider this isolated case: [ Transcript show: 'Beginning';cr. [ Error signal: 'whatever error' ]
on: Error do: [:ex| Transcript show: 'Inner exception..will signal again';cr. ex signal.
]. Transcript show: 'should not be executed';cr. ] on: Error do: [ :ex2 |
Transcript show: 'Parent handler...exception is: ', ex2 printString. ] In Pharo, this method prints in the transcript: Beginning Inner exception..will signal again Parent handler...exception is: Error: whatever error
While in GemStone, I get: Beginning Inner exception..will signal again Parent handler...exception is: a UncontinuableError occurred (error 6011), Execution cannot be continued, 'Exception has already been signaled'
Of course, for use usecase, in my app code, the real fix was to replace #signal in the inner handler to send #pass instead. If I do this, both Pharo and GemStone seem to behave same way. What I would like to understand is what is exactly what is not supported in GemStone regarding the #singal. Is this the limit? I cannot signal an exception at a partent handler that was already singaled in an inner handler?
Thanks in advance, On Mon, Mar 10, 2014 at 8:16 PM, Richard Sargent <[hidden email]> wrote: Mariano Martinez Peck wrote Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Problem with UncontinuableError
|
Administrator
|
Hi Mariano, This has come down to a question of implementation choices versus language design. In GemStone, once an exception is signalled, the VM adds state to the exception object recording information about where the exception occurred, etc. to support #resume, #retry, and so on. On the other hand, we (as Smalltalkers) have had #pass formalized for the last 15 years as the way to invoke an outer exception handler. I asked one of our VM engineers about this and the short answer is a decision to avoid making the VM's job any harder by allowing #signal to be executed multiple times. I think you can agree that the second #signal was not intended to say the exception occurred where the second #signal message was being sent. Far better to be explicit about intentions and use #pass to tell the reader you are sending it to an outer handler. I'm glad you were able to track it down! Richard |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |