Debugging Reraised Exception
Locked
 
|
I have a progress dialog which forks a separate work process to do the
processing code. Any exception happening in the work process is stored. When the main process continues, the stored exception is reraised. A simple snippet demonstrates how exception handling works: | outerException | [0 / 0] on: UnhandledException do: [:exception | outerException := exception parameter. exception return]. outerException copyForReraise searchFrom: thisContext; raise The problem with the code is that debugging the cause of the exception is not possible. To do so a breakpoint must be put in the exception handler. This is however not a solution, as an (another) exception handler will sometimes handle outerException. Besides, I am not only looking at debugging: I also need to write a runtime dump, if outerException is not handled. Does anyone know if I can get a debugger (and a dump) of the original cause of the exception? (This would include the call to SmallInteger>>/ if used with the example above.) My current solution is to make a runtime text dump in the exception handler, store the string, and include that if the #raise of outerException is not handled. This is not very elegant, but works for runtime dumps. To debug problems, a breakpoint must be inserted in the exception handler block. This question has been raised earlier in the context of class Promise, which uses similar code to what I present in my example. Kind regards Runar _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Debugging Reraised Exception
|
|
Maybe the handler could just suspend the work process, and then later
restart it (raising its priority) and #pass the error. The way we've done it is simply to let the work process do normal error handling. Deferring the error raising has the risk that the objects involved in the error situation have changed, so debugging and calculating a dump will give different results than actually existed at the time of the error. In that sense, calculating and storing the dump in the exception is a good idea. If there's only one work process per dialog, what will the dialog be doing after the error and before the main process continues? Presumably the work process can't continue, so it's hard to see what else the main process would be waiting for. Steve > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Runar Jordahl > Sent: 11. huhtikuuta 2011 12:55 > To: [hidden email] > Subject: [vwnc] Debugging Reraised Exception > > I have a progress dialog which forks a separate work process to do the > processing code. Any exception happening in the work process is > stored. When the main process continues, the stored exception is > reraised. > > A simple snippet demonstrates how exception handling works: > > | outerException | > > [0 / 0] on: UnhandledException do: [:exception | > outerException := exception parameter. > exception return]. > > outerException copyForReraise > searchFrom: thisContext; > raise > > The problem with the code is that debugging the cause of the exception > is not possible. To do so a breakpoint must be put in the exception > handler. This is however not a solution, as an (another) exception > handler will sometimes handle outerException. Besides, I am not only > looking at debugging: I also need to write a runtime dump, if > outerException is not handled. > > Does anyone know if I can get a debugger (and a dump) of the original > cause of the exception? > (This would include the call to SmallInteger>>/ if used with the > example above.) > > My current solution is to make a runtime text dump in the exception > handler, store the string, and include that if the #raise of > outerException is not handled. This is not very elegant, but works for > runtime dumps. To debug problems, a breakpoint must be inserted in the > exception handler block. > > This question has been raised earlier in the context of class Promise, > which uses similar code to what I present in my example. > > Kind regards > Runar > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Runar Jordahl
"Runar Jordahl"<[hidden email]> wrote:
> A simple snippet demonstrates how exception handling works: > > | outerException | > > [0 / 0] on: UnhandledException do: [:exception | > outerException := exception parameter. > exception return]. > > outerException copyForReraise > searchFrom: thisContext; > raise When the 'exception return' above runs, the stack unwinds all the way to the handler context, so you're immediately losing all that context about the 0/0 computation. The #copyForReraise doesn't give you the original context back, it is more of a "let's reuse the old exception instance to raise another one that looks a lot like the original". It will have the same parameters but the context/stack is completely different, it's from where the second #raise is called. So the re-raised exception is usually similar enough to be able to write handlers for it (outside of the original context) but certainly not the same. The only way to preserve the context is to not let the associated process proceed (i.e. you have to suspend it) or to make a snapshot/continuation of it that you could restart/debug later. That still won't preserve all the associated state but you could get something you could actually open a debugger on. This is very much like what Seaside does with continuations to allow coming back to certain points of execution. I think that's about as close as you can get. HTH, Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |