Problem catching exception
Locked
 
|
Hi All,
The attachment shows a problem I've encountered in exception processing. Any ideas? George _______________________________________________ Ibm-netrexx mailing list [hidden email] |
ExceptionExample.pdf (93K)
|
Java exceptions that don't need explicit declaration are RuntimeException. NumberFormatException is one of these, you should be able to get it to work by changing:
Catch e = Exception to: Catch e = RuntimeException On 22 October 2010 07:05, George Hovey <[hidden email]> wrote: Hi All, -- Can't tweet, won't tweet! _______________________________________________ Ibm-netrexx mailing list [hidden email]
Alan
-- Needs more cowbell. |
Re: Problem catching exception
|
|
Alan,
You're right -- it works. I'm puzzled why since RuntimeException is a subclass of Exception. I'm going to read the Java Tutorial on exception handling (which I should have done before :-( ). Thanks, George On Fri, Oct 22, 2010 at 10:44 AM, Alan Sampson <[hidden email]> wrote: Java exceptions that don't need explicit declaration are RuntimeException. NumberFormatException is one of these, you should be able to get it to work by changing: _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
To really understand why, you'd need to research RuntimeException in the Java specs; I did once but it's a long time ago so the details are murky. Needless to say it's something that sticks with you once you've been burned by it.
The logic is probably that run-time problems are something that are so common it would be unreasonable to require that programmers handle all possible cases. Alan. On 22 October 2010 08:44, George Hovey <[hidden email]> wrote: Alan, -- Can't tweet, won't tweet! _______________________________________________ Ibm-netrexx mailing list [hidden email]
Alan
-- Needs more cowbell. |
|
|
In reply to this post by George Hovey-2
George,
Reading the java tutorial won't help. This stuff (unchecked exceptions) is handled differently in NetRexx than in java. This is one of my grievances with the language. In java you are forced to either catch checked exceptions or indicate your method "signals" (throws) them. In NetRexx this is optional and controlled by the "strictsignal" compiler option. That is all good and well, I just always use strictsignal. Now here comes the problem you illustrate. In java no action is forced on you regarding unchecked Exceptions (RuntimeException and descendants) but you are very much welcome to catch them jointly with any other by catching Exception or even Throwable. In NetRexx this is not so; the compiler won't allow you to just put an umbrella catch Exception to catch them all. Three workarounds I've come up: - Add "signals RuntimeException" to all your methods. This clearly defeats the initial purpose of distinguishing checked and unchecked exceptions. And is a mess! - Catch RuntimeException specifically as Alan advises. In the bubble them up exception handling strategy I tend to favour this leads many times do duplicate catch blocks with pretty much the same code inside :-( - Trip the compiler over it's toes with a construct like you do with kludge. Once the compiler thinks an Exception might be signaled, it will happily catch any NullPointerException that might be raised. One day I will propose at least a compiler option to change this behaviour... but not today... --- Saludos / Kind regards. David Requena El 22/10/2010 17:44, George Hovey escribió: Alan, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: Problem catching exception
|
|
This certainly explains what I saw comprehensively. My initial reaction is that I like option 1, "signals RuntimeException". Here is my reasoning.
I really want to handle RuntimeException. I already handle Exception because I generate them myself in order to signal, especially, invalid user input. Typically the user supplies me with a complex control file and I cannot easily validate the whole thing before exposing the program logic to it. Instead I pass it directly to the actual parsing methods. When one of these detects an erroneous input, it only understands its small piece of the problem and can only say something like "found 'abc'; expected a number". And it would be quite a brain teaser to maintain some state record that could be displayed to tell all. Instead I rely on the fact that that state is represented by the totality of methods in activation at time of error. I call such methods in Do ... Catch ... End statements and use the catch to add to a stack of messages describing the actual context in terms understandable to non-geeks [ie, NOT a Java stack trace]. The catch block then signals a new Exception to continue the chain until it reaches main, where the messages are printed in reverse order. The user might see something like 1. While looking at line 5 of your control file '<name of control file>', '<line 5 of control file>', 2. I found a data file '<data file name>' and opened it. 3. On its line 10 I found... etc. Usually the user is able to debug his own input. I've been doing this for years and find it very satisfactory. However, it only works if I generate the initial Exception. If a RuntimeException occurs I never get control, for reasons which are now clear, and the user sees a Java stack trace. So I will now work on annotating the stack trace with the information in my catch blocks. Any thoughts (you ominously describe option 1 as "a mess")? Thanks, George P.S. And thanks for warning me off of a useless trip to the Java Tutorial. On Fri, Oct 22, 2010 at 12:28 PM, David Requena <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: Problem catching exception
|
|
In reply to this post by David Requena
Hello David,
I did try a lot to find out the algorithm you describe below. Thanks a lot for the clarity and insight :-) Thomas. =================================================== Am 22.10.2010 18:28, schrieb David Requena: George, --
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by George Hovey-2
George,
In general I think a case could be made about the whole signal/catch/finally model being a mess in itself but, well.. What you describe is one of several strategies that can be applied with good results. Another would be in a system with several logical layers to re-throw at each layer (probably chaining each Exception as a cause on the way up). And many more, of course. The thing with option 1 is: there is a point in the distinction between checked and unchecked exceptions. The former occur at very specific places and involve specific context. All of which you can "translate" (like in above schemes) to something useful for your user. The latter can be raised everywhere, they most likely uncover some programming error like trying to access some uninitialized object reference raising a NullPointerException. Unchecked exception conditions are also grouped into two separate sub-trees in the java class hierarchy formed by java.lang.RuntimeException, java.lang.Error and their respective descendants. What I meant by a mess would be to be appending "signals RuntimeException, Error" to any single method in every single class used in any single program so I can put a single "catch t=Throwable" at the top level. And why would I need to do that? Well, it's the only way to be sure every possible execution path has been specified to signal these exception conditions. IOW the compiler will agree to process my program without balking at me about unsignalled exceptions. And why do I bother? Well, in my book a user ever seeing an untamed stack trace is a bug. I want to be able to tell him there wasn't enough free memory to load his 2.5GB file but that closing some Internet Explorer windows might help. Or tell him he has discovered a bug and ask politely so send back the weird-info-shown below so I can fix it. Besides, in these days of multi-threading your program won't simply die and show a stack trace. Most likely some thread will die printing the ST to somewhere not to be found and the hole app will remain alive but badly hampered. To make things even worse your user wont't probably see any stack trace. Take a swing application for instance: - an unchecked exception is raised in event handling code for say, a button. - the awt thread is very resilient and wont die. It will print a stack trace and go on happily. - but where does that trace go? As the app was started by a double click, there is no text console. It goes to the java console. - the java console is disabled by default on most windows jres. - is very unlikely your users going to advanced java settings at control panel and activating it on their own. In short: They won't see anything at all. Just a button that does nothing. On the other hand, you won't be able to do much to fix the problem with just that information... --- Saludos / Kind regards. David Requena El 22/10/2010 21:54, George Hovey escribió: This certainly explains what I saw comprehensively. My initial reaction is that I like option 1, "signals RuntimeException". Here is my reasoning. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: Problem catching exception
|
|
David,
Thanks for your, as ever, detailed and considered response. There is quite a bit of food for thought here, and it will take some time to chew and digest it. Just a couple of random reactions for now. Interesting to hear your slant on problems specific to GUIs. My programs only have GUIs where this is essential to functioning (I wrote 4 in 7 years). But I sidestep the output issue by requiring the user to start from a command window. This is well within the expectations of my particular users (scientists) but obviously not a general solution. I pervasively use a Run Log file (class RunLog) which records any output I think helps. It contains mixtures of logging and debugging, all clearly labeled and accompanied by a jEdit mode file to color it helpfully (users are taught to use jEdit, as least as a viewer). It can be arranged to be written cumulatively (with warnings about its growing size!) to hunt for rarely occurring problems. It is designed as a singleton in such a way that the first class to invoke it gets to set its characteristics (name, etc), while later invocations from other classes will fail (harmlessly) to set the characteristics, but still can use the class for logging. [In a GUI situation, the file could be opened in a "well known" directory.] I'll want to discuss several of your points in more detail when they have sunk in a bit. On Wed, Oct 27, 2010 at 5:03 PM, David Requena <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Just a couple quick comments below
--- Saludos / Kind regards. David Requena El 28/10/2010 2:52, George Hovey escribió: David, No specific slant on GUI. That was meant just an example of a situation on which the NetRexx stance of "Catching an exception which is not explicitly signalled is an error" becomes inconvenient. The issue is more one of multi-threading than of GUIness. Of course, swing GUIs are multi-threaded by nature. Besides, I have a dream: Someday the world will open its eyes, NetRexx will become mainstream and all kinds of NetRexx coded apps. will be common among general public. That probably means GUI galore. Here's another non GUI example: I have a JDBC pool implemented in NetRexx. It has a background thread which periodically closes unused connections up to a certain minimum. If an unchecked exception is raised in that thread and I wasn't catching/reacting to it, the system wouldn't crash. It simply would stop collecting unused connections. Probably a month latter my tomcat instance will die with an OutOfMemoryError or a StackOverflowError signalled at a totally unrelated module. At that point the server administrator probably won't relate this error to that NullPointerException he saw on the log far ago (and that'd be if he was regularly monitoring the log). After all, the server has been running ok long after the original exception and DB connectivity seemed all right. Sadly, that administrator could even be me, the system developer!! I pervasively use a Run Log file (class RunLog) which records any output I think helps. It contains mixtures of logging and debugging, all clearly labeled and accompanied by a jEdit mode file to color it helpfully (users are taught to use jEdit, as least as a viewer). It can be arranged to be written cumulatively (with warnings about its growing size!) to hunt for rarely occurring problems. It is designed as a singleton in such a way that the first class to invoke it gets to set its characteristics (name, etc), while later invocations from other classes will fail (harmlessly) to set the characteristics, but still can use the class for logging. [In a GUI situation, the file could be opened in a "well known" directory.] I think comprehensive logging is always a good idea. I'd say it's a must on many domains as on servers for instance. I think you're right it all may depend on what your user population actually is. Frankly I don't see the typical user of your state-of-the-art torrent client go diving into a log file to see why his movies aren't coming down from the internet. Certainly the average Vuze user wouldn't... But is nice to have it. You can always have the user send the log to you if he somehow gets to know there's a problem. I'll want to discuss several of your points in more detail when they have sunk in a bit. You'll be most welcome, you know it :-) Oh, OK, that weren't just quick comments.. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: Problem catching exception
|
|
Your problems are very different from mine -- me and my users are in the same room.
On Thu, Oct 28, 2010 at 8:51 AM, 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 |