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. |
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? - Bert - smime.p7s (5K) Download Attachment |
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? |
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? 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 |
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 |
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? - Bert - smime.p7s (5K) Download Attachment |
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 |
I think it is preferrable to write a tool for the suspended process. That tool could have full control over stack manipulation.
Best, Marcel |
Free forum by Nabble | Edit this page |