How to view an old Error in the debugger?

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

How to view an old Error in the debugger?

Chris Muller-4
My app signaled an Error, which was handled at a higher level to
present a nice message to the user.

However, I want to see the stack that led to it.  I have the Error
instance that was signaled and I see I have ToolSet class>>#debug:, et
al.

But by the time it unwinds and I get hold of Error, its
signalerContext is gone, so I can't get anything useful from the
debugger.

As this script shows, in the handler I still have access to the
signalerContext, but once I unwind back out, its gone.

So is there a way to debug an old error?

     | errorToDebug |
     errorToDebug := [Error signal]
          on: Error
          do:
               [ : err | errorToDebug := err.
               self assert: err signalerContext sender notNil.
               err ].
     self assert: errorToDebug signalerContext sender notNil

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: How to view an old Error in the debugger?

Bert Freudenberg
On 02.03.2015, at 16:11, Chris Muller <[hidden email]> wrote:

>
> My app signaled an Error, which was handled at a higher level to
> present a nice message to the user.
>
> However, I want to see the stack that led to it.  I have the Error
> instance that was signaled and I see I have ToolSet class>>#debug:, et
> al.
>
> But by the time it unwinds and I get hold of Error, its
> signalerContext is gone, so I can't get anything useful from the
> debugger.
>
> As this script shows, in the handler I still have access to the
> signalerContext, but once I unwind back out, its gone.
>
> So is there a way to debug an old error?
You have to suspend the process with the error, and do the error handling in another process. That way you can deal with the error before it is unwound, you can resume etc.

- Bert -






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to view an old Error in the debugger?

Chris Muller-3
On Tue, Mar 3, 2015 at 5:59 PM, Bert Freudenberg <[hidden email]> wrote:

> On 02.03.2015, at 16:11, Chris Muller <[hidden email]> wrote:
>>
>> My app signaled an Error, which was handled at a higher level to
>> present a nice message to the user.
>>
>> However, I want to see the stack that led to it.  I have the Error
>> instance that was signaled and I see I have ToolSet class>>#debug:, et
>> al.
>>
>> But by the time it unwinds and I get hold of Error, its
>> signalerContext is gone, so I can't get anything useful from the
>> debugger.
>>
>> As this script shows, in the handler I still have access to the
>> signalerContext, but once I unwind back out, its gone.
>>
>> So is there a way to debug an old error?
>
> You have to suspend the process with the error, and do the error handling in another process. That way you can deal with the error before it is unwound, you can resume etc.

That makes sense but I still want my app to handle the error the way
it does presenting the messageText, but I want to add a button,
"Debug" which will open up what happened in the debugger.  The process
which the error occurs in is the UI process so I can't suspending it.
It seems like I want to somehow clone it.  Wait..  A Continuation!?
Is that what I need?

Reply | Threaded
Open this post in threaded view
|

Re: How to view an old Error in the debugger?

Bert Freudenberg
On 03.03.2015, at 18:59, Chris Muller <[hidden email]> wrote:

>
> On Tue, Mar 3, 2015 at 5:59 PM, Bert Freudenberg <[hidden email]> wrote:
>>
>> You have to suspend the process with the error, and do the error handling in another process. That way you can deal with the error before it is unwound, you can resume etc.
>
> That makes sense but I still want my app to handle the error the way
> it does presenting the messageText, but I want to add a button,
> "Debug" which will open up what happened in the debugger.  The process
> which the error occurs in is the UI process so I can't suspending it.
> It seems like I want to somehow clone it.  Wait..  A Continuation!?
> Is that what I need?
What you need is a prettier PreDebugWindow. This used to be what was shown before the actual debugger (in openNotifierContents:label:) but that's now toolbuilderified.

In any case, that method is still the one that schedules a new UI process to debug the old UI process. You can customize it to show a nice and friendly notification instead of the usual pink pre-debug notifier.

- Bert -






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Removing class PreDebugWindow (was: How to view an old Error in the debugger?)

David T. Lewis
On Tue, Mar 03, 2015 at 07:56:02PM -0800, Bert Freudenberg wrote:

> On 03.03.2015, at 18:59, Chris Muller <[hidden email]> wrote:
> >
> > On Tue, Mar 3, 2015 at 5:59 PM, Bert Freudenberg <[hidden email]> wrote:
> >>
> >> You have to suspend the process with the error, and do the error handling in another process. That way you can deal with the error before it is unwound, you can resume etc.
> >
> > That makes sense but I still want my app to handle the error the way
> > it does presenting the messageText, but I want to add a button,
> > "Debug" which will open up what happened in the debugger.  The process
> > which the error occurs in is the UI process so I can't suspending it.
> > It seems like I want to somehow clone it.  Wait..  A Continuation!?
> > Is that what I need?
>
> What you need is a prettier PreDebugWindow. This used to be what was shown before the actual debugger (in openNotifierContents:label:) but that's now toolbuilderified.
>

PreDebugWindow is unreferenced since a long time. The debug notifier is now
created with ToolBuilder. Is there any reason that PreDebugWindow should
stay in the image?

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Removing class PreDebugWindow (was: How to view an old Error in the debugger?)

Bert Freudenberg
On 06.03.2015, at 01:07, David T. Lewis <[hidden email]> wrote:

>
> On Tue, Mar 03, 2015 at 07:56:02PM -0800, Bert Freudenberg wrote:
>> On 03.03.2015, at 18:59, Chris Muller <[hidden email]> wrote:
>>>
>>> On Tue, Mar 3, 2015 at 5:59 PM, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>> You have to suspend the process with the error, and do the error handling in another process. That way you can deal with the error before it is unwound, you can resume etc.
>>>
>>> That makes sense but I still want my app to handle the error the way
>>> it does presenting the messageText, but I want to add a button,
>>> "Debug" which will open up what happened in the debugger.  The process
>>> which the error occurs in is the UI process so I can't suspending it.
>>> It seems like I want to somehow clone it.  Wait..  A Continuation!?
>>> Is that what I need?
>>
>> What you need is a prettier PreDebugWindow. This used to be what was shown before the actual debugger (in openNotifierContents:label:) but that's now toolbuilderified.
>>
>
> PreDebugWindow is unreferenced since a long time. The debug notifier is now
> created with ToolBuilder. Is there any reason that PreDebugWindow should
> stay in the image?
Can't think of any ...

- Bert -






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing class PreDebugWindow (was: How to view an old Error in the debugger?)

marcel.taeumel (old)
In Vivide, I do it like this:

https://github.com/hpi-swa/vivide/blob/master/repository/Vivide.package/ViToolSet.class/class/debug.context.label.contents.fullView..st

https://github.com/hpi-swa/vivide/blob/master/repository/Vivide.package/VivideLight.class/instance/openDebugger..st

I still use an instance of Debugger for its convenience methods.

The error handling stuff might as well be kept on the stack. As you can see, I get rid of them for now. :-)

Maybe this helps.

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Removing class PreDebugWindow (was: How to view an old Error in the debugger?)

marcel.taeumel (old)
I think it is preferrable to write a tool for the suspended process. That tool could have full control over stack manipulation.

Best,
Marcel