How to identify source of an exception?
Locked
How to identify source of an exception?
 
|
I use NetRexx in a real time context where rare and/or unreproducible errors sometimes occur while the program is being run by a scientist-user. To track these down I need to gather as much information as possible at the time of error. In support of this I supply each program with a cumulative log for postmortem analysis, and write extensive diagnostic information to the log.
One vexing problem occurs when the method generating the exception is unknown because it is not monitored by its own Catch clause. For example, in a DO instruction, Do Statement 1 Statement 2 . . . Statement N Catch Exception Exception handler End Does NetRexx provide a means of determining which statement generated the exception? Any other thoughts on exception handling? George _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
On 16 July 2010 08:21, George Hovey <[hidden email]> wrote:
One vexing problem occurs when the method generating the exception is unknown because it is not monitored by its own Catch clause. For example, in a DO instruction, It's just possible that your error is something other than a java.lang.Exception (i.e. a java.lang.Error or java.lang.Throwable) You could try changing your Catch clause to catch a Throwable and see if it works. Alan. -- Can't tweet, won't tweet! _______________________________________________ Ibm-netrexx mailing list [hidden email]
Alan
-- Needs more cowbell. |
Re: How to identify source of an exception?
|
|
The exception is caught all right, I just don't know how to determine which of the N statements generated it.
George On Fri, Jul 16, 2010 at 11:40 AM, Alan Sampson <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
George -
Can you run with TRACE METHODS for a while or would that impact performance too much? -- Kermit On 7/16/2010 12:29 PM, George Hovey wrote: The exception is caught all right, I just don't know how to determine which of the N statements generated it. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
In reply to this post by George Hovey-2
George,
Aren't you calling printStackTrace() method on the caught Exception object? This prints full trace with source file names and line numbers on the error stream. Incidentally you need to compile with option 'format' to get line numbers to match the ones in your NetRexx sources. - Saludos / Kind regards, David Requena -----Original Message----- From: George Hovey <[hidden email]> Sender: [hidden email] Date: Fri, 16 Jul 2010 15:29:59 To: IBM Netrexx<[hidden email]> Reply-To: IBM Netrexx <[hidden email]> Subject: Re: [Ibm-netrexx] How to identify source of an exception? _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
Do you know how to use the "format" option in an Ant build? That could
help my debugging - right now I have to save the generated Java code and check it to find the NetRexx line that failed. -- Kermit On 7/16/2010 2:11 PM, David Requena wrote: > George, > > Aren't you calling printStackTrace() method on the caught Exception object? This prints full trace with source file names and line numbers on the error stream. > > Incidentally you need to compile with option 'format' to get line numbers to match the ones in your NetRexx sources. > > - > Saludos / Kind regards, > David Requena > > -----Original Message----- > From: George Hovey <[hidden email]> > Sender: [hidden email] > Date: Fri, 16 Jul 2010 15:29:59 > To: IBM Netrexx<[hidden email]> > Reply-To: IBM Netrexx <[hidden email]> > Subject: Re: [Ibm-netrexx] How to identify source of an exception? > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > > Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
In reply to this post by Kermit Kiser
Kermit,
I'm not enthusiastic about trace - I suspect it would generate a mind-boggling amount of output. Also, the exceptions sometimes occur very infrequently (hours, days). Thanks, george
On Fri, Jul 16, 2010 at 4:12 PM, Kermit Kiser <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
I'm still curious about your original problem so I prepared/tested the following code snippet: ===== Code starts ===== -- Test PST info on a DO instruction body options noformat class TestPST method main(args=String[]) static SomeOtherClassInstance = SomeOtherClass() Do SomeOtherClassInstance.NonNPEThrowerMethod1() SomeOtherClassInstance.NPEThrowerMethod1() SomeOtherClassInstance.NonNPEThrowerMethod2() Catch ex=Exception ex.PrintStackTrace() End class SomeOtherClass private method NonNPEThrowerMethod1() nop method NonNPEThrowerMethod2() nop method NPEThrowerMethod1() signals NullPointerException nullVector = Vector foo =nullVector.elementAt(0) -- this will signal an NPE Say foo.toString() ===== Code ends ===== When run this prints: java.lang.NullPointerException at SomeOtherClass.NPEThrowerMethod1(TestPST.nrx:28) at TestPST.main(TestPST.nrx:11) As you see full info on class, method, file and line number is given for the whole stack of method calls which lead to an Exception being signalled. What further information are you after? Of course more things can be done with the stacktrace than just printing it to System.err As noted previously elsewhere the 'noformat' option is required for the line numbers given actually matching your NetRexx sources. --- Saludos / Kind regards. David Requena El 17/07/2010 4:40, George Hovey escribió: Kermit, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
Hi David,
What you have shown is exactly the info I want, but not necessarily in the most desirable form. I already have my own internal scheme for handling some exceptions. Here is an example from a special purpose assembler used by digital designers. It is displayed in a command window and recorded in the program's cumulative log file. |---------------------------------------------------------| | Fatal Error: Trace follows. | | Last entry is method initially detecting error. | |---------------------------------------------------------| | 1. Method `pb3.main` reports... | | Locating all local macro definitions. | |---------------------------------------------------------| | 2. Method `Macros.FindLocalMacroDefs` reports... | | locating all local -MDef; bad def at line=157: | | (°-MDef MN.MainProgram -Enter°) | |---------------------------------------------------------| | 3. Method `MacroDesc.InitLocalDesc` reports... | | Malformed °-MDef° directive | |---------------------------------------------------------| | 4. Method `Macros.ParseMacroDirective` reports... | | °-MDef° directive must not have °IN.<InstanceName>°. | |---------------------------------------------------------| When I detect a user error, I signal an exception which is caught by all of my methods currently in execution. Each one records (hopefully) helpful context info to aid the user in deducing what went wrong. These are accumulated so they can be displayed in "reverse" order. This does not deal with conventional programming errors on my part, or multithreading problems. What I want to do is to monitor all other statements with Catch clauses so I can monitor these and fit them smoothly (identified as "internal" errors so the user won't think he did something wrong) into the above scheme. It didn't occur to me to make use of Java's stack trace because I wouldn't dream of showing it to a user. However, I take your point that I should be looking at Java, not NetRexx. I've done so and it looks like, for my purpose, GetStackTrace() will work even better than PrintStackTrace(). I'm tied up on other work right now, but I will have a go at it when I'm free. Re the NOFORMAT option, I have it in my invocation of NetRexxC. BTW, I always read your posts no matter what the subject -- I usually learn something useful. George On Sun, Jul 18, 2010 at 5:37 PM, David Requena <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by George Hovey-2
Exceptions are not meant to be branch statements. Its considered bad form in java. Imho
From: [hidden email] <[hidden email]> To: IBM Netrexx <[hidden email]> Sent: Mon Jul 19 10:29:26 2010 Subject: Re: [Ibm-netrexx] How to identify source of an exception? What you have shown is exactly the info I want, but not necessarily in the most desirable form. I already have my own internal scheme for handling some exceptions. Here is an example from a special purpose assembler used by digital designers. It is displayed in a command window and recorded in the program's cumulative log file. |---------------------------------------------------------| | Fatal Error: Trace follows. | | Last entry is method initially detecting error. | |---------------------------------------------------------| | 1. Method `pb3.main` reports... | | Locating all local macro definitions. | |---------------------------------------------------------| | 2. Method `Macros.FindLocalMacroDefs` reports... | | locating all local -MDef; bad def at line=157: | | (°-MDef MN.MainProgram -Enter°) | |---------------------------------------------------------| | 3. Method `MacroDesc.InitLocalDesc` reports... | | Malformed °-MDef° directive | |---------------------------------------------------------| | 4. Method `Macros.ParseMacroDirective` reports... | | °-MDef° directive must not have °IN.<InstanceName>°. | |---------------------------------------------------------| When I detect a user error, I signal an exception which is caught by all of my methods currently in execution. Each one records (hopefully) helpful context info to aid the user in deducing what went wrong. These are accumulated so they can be displayed in "reverse" order. This does not deal with conventional programming errors on my part, or multithreading problems. What I want to do is to monitor all other statements with Catch clauses so I can monitor these and fit them smoothly (identified as "internal" errors so the user won't think he did something wrong) into the above scheme. It didn't occur to me to make use of Java's stack trace because I wouldn't dream of showing it to a user. However, I take your point that I should be looking at Java, not NetRexx. I've done so and it looks like, for my purpose, GetStackTrace() will work even better than PrintStackTrace(). I'm tied up on other work right now, but I will have a go at it when I'm free. Re the NOFORMAT option, I have it in my invocation of NetRexxC. BTW, I always read your posts no matter what the subject -- I usually learn something useful. George On Sun, Jul 18, 2010 at 5:37 PM, David Requena <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
Mike,
If that's addressed to me, I haven't a clue to what you mean. George On Mon, Jul 19, 2010 at 10:48 AM, Measel, Mike <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
In reply to this post by George Hovey-2
George,
Hmm, I see... Perhaps you could tackle this catching/logging/re-throwing exceptions of increasing abstraction level. Nothing prevents you to implement a high level BadDefinitionFoundException which might be initially triggered by a lower level BadArgumentException. At each step you get a the first StackTraceElement, log in any fancy fashion to the 'users log' using info retrieved from it, then throw a new exception so the prior calling method gets a chance to know something went bad (and do it own logging, re-throw, etc..) Alternatively you could go chaining exceptions then at the top level do all the logging in reverse order as per your example. This would give the added benefit of being able to log the full stacktrace to a separate 'developers log'. Or probably a million other things; the whole exceptions system is pretty complicated and difficult to use right :-( --- Saludos / Kind regards. David Requena El 19/07/2010 16:29, George Hovey escribió: Hi David, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
On Mon, Jul 19, 2010 at 5:12 PM, David Requena <[hidden email]> wrote:
> George, > > Hmm, I see... > > Perhaps you could tackle this catching/logging/re-throwing exceptions of > increasing abstraction level. Nothing prevents you to implement a high level > BadDefinitionFoundException which might be initially triggered by a lower > level BadArgumentException. > > At each step you get a the first StackTraceElement, log in any fancy fashion > to the 'users log' using info retrieved from it, then throw a new exception > so the prior calling method gets a chance to know something went bad (and do > it own logging, re-throw, etc..) > > Alternatively you could go chaining exceptions then at the top level do all > the logging in reverse order as per your example. This would give the added > benefit of being able to log the full stacktrace to a separate 'developers > log'. The JVM already does this quite nicely via the initCause() method on the Throwable class. This allows you to throw whatever exception you feel appropriate without losing the original cause of the exception. printStackTrace() handles all of the chaining for you. Rick > > Or probably a million other things; the whole exceptions system is pretty > complicated and difficult to use right :-( > > --- > Saludos / Kind regards. > David Requena > > El 19/07/2010 16:29, George Hovey escribió: > > Hi David, > > What you have shown is exactly the info I want, but not necessarily in the > most desirable form. I already have my own internal scheme for handling > some exceptions. Here is an example from a special purpose assembler used > by digital designers. It is displayed in a command window and recorded in > the program's cumulative log file. > > > |---------------------------------------------------------| > | Fatal Error: Trace follows. | > | Last entry is method initially detecting error. | > |---------------------------------------------------------| > | 1. Method `pb3.main` reports... | > | Locating all local macro definitions. | > |---------------------------------------------------------| > | 2. Method `Macros.FindLocalMacroDefs` reports... | > | locating all local -MDef; bad def at line=157: | > | (°-MDef MN.MainProgram -Enter°) | > |---------------------------------------------------------| > | 3. Method `MacroDesc.InitLocalDesc` reports... | > | Malformed °-MDef° directive | > |---------------------------------------------------------| > | 4. Method `Macros.ParseMacroDirective` reports... | > | °-MDef° directive must not have °IN.<InstanceName>°. | > |---------------------------------------------------------| > > When I detect a user error, I signal an exception which is caught by all of > my methods currently in execution. Each one records (hopefully) helpful > context info to aid the user in deducing what went wrong. These are > accumulated so they can be displayed in "reverse" order. > > This does not deal with conventional programming errors on my part, or > multithreading problems. What I want to do is to monitor all other > statements with Catch clauses so I can monitor these and fit them smoothly > (identified as "internal" errors so the user won't think he did something > wrong) into the above scheme. > > It didn't occur to me to make use of Java's stack trace because I wouldn't > dream of showing it to a user. However, I take your point that I should be > looking at Java, not NetRexx. I've done so and it looks like, for my > purpose, GetStackTrace() will work even better than PrintStackTrace(). I'm > tied up on other work right now, but I will have a go at it when I'm free. > > Re the NOFORMAT option, I have it in my invocation of NetRexxC. > > BTW, I always read your posts no matter what the subject -- I usually learn > something useful. > > George > > > On Sun, Jul 18, 2010 at 5:37 PM, David Requena <[hidden email]> wrote: >> >> George, >> >> I'm still curious about your original problem so I prepared/tested the >> following code snippet: >> >> ===== Code starts ===== >> -- Test PST info on a DO instruction body >> options noformat >> >> class TestPST >> >> method main(args=String[]) static >> >> SomeOtherClassInstance = SomeOtherClass() >> Do >> SomeOtherClassInstance.NonNPEThrowerMethod1() >> SomeOtherClassInstance.NPEThrowerMethod1() >> SomeOtherClassInstance.NonNPEThrowerMethod2() >> >> Catch ex=Exception >> ex.PrintStackTrace() >> End >> >> class SomeOtherClass private >> >> method NonNPEThrowerMethod1() >> nop >> >> method NonNPEThrowerMethod2() >> nop >> >> method NPEThrowerMethod1() signals NullPointerException >> nullVector = Vector >> foo =nullVector.elementAt(0) -- this will signal an NPE >> Say foo.toString() >> >> ===== Code ends ===== >> >> When run this prints: >> >> java.lang.NullPointerException >> at SomeOtherClass.NPEThrowerMethod1(TestPST.nrx:28) >> at TestPST.main(TestPST.nrx:11) >> >> As you see full info on class, method, file and line number is given for >> the whole stack >> of method calls which lead to an Exception being signalled. What further >> information are >> you after? >> >> Of course more things can be done with the stacktrace than just printing >> it to System.err >> >> As noted previously elsewhere the 'noformat' option is required for the >> line numbers given >> actually matching your NetRexx sources. >> >> >> --- >> Saludos / Kind regards. >> David Requena >> >> El 17/07/2010 4:40, George Hovey escribió: >> >> Kermit, >> I'm not enthusiastic about trace - I suspect it would generate a >> mind-boggling amount of output. Also, the exceptions sometimes occur very >> infrequently (hours, days). >> Thanks, >> george >> >> On Fri, Jul 16, 2010 at 4:12 PM, Kermit Kiser <[hidden email]> >> wrote: >>> >>> George - >>> >>> Can you run with TRACE METHODS for a while or would that impact >>> performance too much? >>> >>> -- Kermit >>> >>> >>> On 7/16/2010 12:29 PM, George Hovey wrote: >>> >>> The exception is caught all right, I just don't know how to determine >>> which of the N statements generated it. >>> >>> George >>> >>> On Fri, Jul 16, 2010 at 11:40 AM, Alan Sampson <[hidden email]> >>> wrote: >>>> >>>> On 16 July 2010 08:21, George Hovey <[hidden email]> wrote: >>>>> >>>>> One vexing problem occurs when the method generating the exception is >>>>> unknown because it is not monitored by its own Catch clause. For example, >>>>> in a DO instruction, >>>>> >>>>> Do >>>>> Statement 1 >>>>> Statement 2 >>>>> . >>>>> . >>>>> . >>>>> Statement N >>>>> Catch Exception >>>>> Exception handler >>>>> End >>>>> >>>> >>>> It's just possible that your error is something other than a >>>> java.lang.Exception (i.e. a java.lang.Error or java.lang.Throwable) You >>>> could try changing your Catch clause to catch a Throwable and see if it >>>> works. >>>> >>>> Alan. >>>> >>>> -- >>>> Can't tweet, won't tweet! >>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> >>>> >>> >>> ________________________________ >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> >>> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> >>> >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
El 19/07/2010 23:32, Rick McGuire escribió: Well, that's what I was referring to by 'chaining' either by using initCause() orAlternatively you could go chaining exceptions then at the top level do all > the logging in reverse order as per your example. This would give the added > benefit of being able to log the full stacktrace to a separate 'developers > log'.The JVM already does this quite nicely via the initCause() method on the Throwable class. This allows you to throw whatever exception you feel appropriate without losing the original cause of the exception. printStackTrace() handles all of the chaining for you. by instantiating the new exceptions with the constructor which takes a Throwable as in ... catch e=Exception Say "Something" signal Exception(e) ... The thing is that George intends to log in a very precise format and in reverse order. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: How to identify source of an exception?
|
|
In reply to this post by David Requena
from parse version a b c d e f i get
REXX-ooRexx_4.0.0(MT) 6.03 15 Aug 2009 'f' is blank bobh On Mon, Jul 19, 2010 at 4:12 PM, David Requena <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |