Error Handling
in [Java Help]
|
From: markspace on 29 May 2010 02:22 Rhino wrote: > Our various recent discussions have convinced me that many error situations > should probably not be handled via Exceptions, particularly things like > input errors on GUIs. I know there is a school of thought that says In general, log everything, and throw on everything. This contradicts some advice you've got already on this thread. I'll try to justify my reasons. > exceptions are a reasonable approach to some input errors but that seems to > be the minority opinion; most people prefer other ways. As a special case, when validating an input value it isn't really "wrong" for the value to be incorrect, so it's OK to return true or false and not throw an exception. If you receive a bad value where you weren't expecting it, throw an exception. > I've seen, written, or used programs where that message would be displayed > back on the input panel, typically in a position that the builders of the > system think is going to be the most readily seen, like just above the input As others have mentioned, I like this one best too. Acknowledging a pop-up is annoying and takes a "user gesture." Too many user gestures and a program is just plain bothersome and hard to use. > I'm mostly concerning with > Java applications today, as opposed to applets or servlets, but I write all > of those types so I'm interested in the best way of error handling for all > types of Java programs. I happen to be dealing with a JEE app that was written by someone who appears to be a decent but inexperienced coder. All code captures any exception, prints a stack trace, and then just returns. This results in a hung app if something important fails, and it happens that the database is unstable right now. But the servlet can't know that the database has gone off-line, because there's no exception, so the servlet just calls the next method and everything hangs. Throwing exceptions instead of printing a message and then swallowing them would have resulted an app that was easier to test, rather than one that just timed out but gave no indication to the tester when or why. Throw all exceptions, until you get to the user's level, then do something to make a nice error result. In this case the servlet should have caught the error, logged it, and then dispatch a nice error page instead of just hanging forever. > And what would the code in the method that detects the error look like? I'm > picturing if statements that test the input and then format a message if an > error is seen. Throw an exception, and format its message for the programmer. Include all relevant arguments and any relevant internal objects too, even if private. For example, on an array index out of range exception, return the index value the programmer passed in, so the programmer can see what they did, and the size of the array that was exceeded, so the programmer can see what they should have done. Let the higher level code decide what message the user should see. > Also, am I correct in thinking that errors of the kind I am describing > should not be logged, even at a very detailed level, since the log should > only be for serious things that would involve a system administrator? I log everything. When I'm writing code, I'm normally writing the unit test at the same time. I crank up the log level to FINER or ALL, put everything I need to see in log messages, and add a ConsoleHandler so I can see it easily. Then when it all seems to work, I reduce the log level but I leave that logging still there. That way all the work I went through when deciding what to log is not lost, and it's all still there if I or someone else should need it again. Don't ignore optimization: Use "isLoggable(Level)" everywhere and minimize the places where you have to call it, but don't stint either. Your time is more valuable that the CPU's. This is the true value of "log everything," imo. Having a routine that's already well instrumented when you need to go back to it and debug something is a great time-saver in the long run. > Typically, it's because I've made a typo or forgotten the range of > acceptable values for a parameter to the method. This should always be checked and should throw IllegalArgumentException, with the messages for the programmer about what the wrong value was and what range it should of been, as I mention above. > there is not going to be a GUI on which > to display the message for that error. So how should that be handled? It's OK to wrap the entire main method with a try-catch that results in a bland "Internal error, please call technical support" message so the user never sees internal error messages. > Again, I'm assuming that errors like this shouldn't be logged. Log everything. Then, when the user calls technical support, the support technician can ask the user to email the logs, so tech support can figure out what went wrong. > 3. Serious errors causes by programmer error. Throw an exception. Let higher level code decide if it wants to log or propagate the exception. This makes testing much easier. And higher level code will be more flexible because it decides how the program flows, not you. At the higher level, log it when you no longer propagate it. > 4. Really bad errors not caused by the programmer. > > I assume that ALL such situations should be logged. Throw an exception, let higher level code deal with it. Always log it at the higher level, and then display an appropriate error message. > What notifications should users receive in such cases? What notifications > should batch programs make in those cases? Depends on whether your user is technical or not. Technical users might appreciate the error trace if they have access to your source code. Non-technical users probably want to call tech support. Log these at the higher levels of code, throw at the lower levels. Because technical vs. non-technical might change over the life of the software and you don't want to have to hunt down every log and throw, just a few at the top level.
From: Rhino on 29 May 2010 16:50 "Lew" <noone(a)lewscanon.com> wrote in message news:htq17k$45n$1(a)news.albasani.net... > Daniel Pitts wrote: >>> You might try your local library or book store. Near where I live, >>> Borders >>> is a good place to pick up a book and read it before buying it. >>> >>> Some might say this is a dubious activity, however I buy plenty of books >>> and also patronize the coffee shop frequently. > > Rhino wrote: >> That would be a better strategy for a situation where I just want to get >> one >> or two details and could write them down or memorize them while >> "browsing". >> But the description makes it look like there's lot of good stuff inside, >> far >> more than I could reasonably memorize or summarize even if I spent a >> couple >> of hours browsing. > > You just will come up with any excuse not to read, won't you? > > First it was that you can't afford it. Then people (repeatedly) suggest a > way to do it for free and you now claim that there isn't enough time in > those situations to read. Oh, and what was your excuse not to use a > library? > >> Thanks for the suggestion though! It would be good in other situations >> :-) > > Yeah, situations that involve a programmer actually willing to do what it > takes to learn their craft. Except for those situations, I guess the > suggestions are pretty useless. Oh please! Could YOU pick up a significant amount of detail - either via memorization or making notes - from a 400 or 500 page book in just a couple of hours of reading? Do YOU have so much influence that you can put in a request for an interlibrary loan and have the book appear in a mere day or two? If so, my hat is off to you for you are clearly a superhuman, not a mere mortal like me. -- Rhino
From: Rhino on 29 May 2010 17:09 "markspace" <nospam(a)nowhere.com> wrote in message news:htqbqp$oh6$1(a)news.eternal-september.org... > Rhino wrote: > >> Our various recent discussions have convinced me that many error >> situations should probably not be handled via Exceptions, particularly >> things like input errors on GUIs. I know there is a school of thought >> that says > > > In general, log everything, and throw on everything. This contradicts > some advice you've got already on this thread. I'll try to justify my > reasons. > > >> exceptions are a reasonable approach to some input errors but that seems >> to be the minority opinion; most people prefer other ways. > > > As a special case, when validating an input value it isn't really "wrong" > for the value to be incorrect, so it's OK to return true or false and not > throw an exception. If you receive a bad value where you weren't > expecting it, throw an exception. > > >> I've seen, written, or used programs where that message would be >> displayed back on the input panel, typically in a position that the >> builders of the system think is going to be the most readily seen, like >> just above the input > > > As others have mentioned, I like this one best too. Acknowledging a > pop-up is annoying and takes a "user gesture." Too many user gestures and > a program is just plain bothersome and hard to use. > > >> I'm mostly concerning with Java applications today, as opposed to applets >> or servlets, but I write all of those types so I'm interested in the best >> way of error handling for all types of Java programs. > > > I happen to be dealing with a JEE app that was written by someone who > appears to be a decent but inexperienced coder. All code captures any > exception, prints a stack trace, and then just returns. This results in a > hung app if something important fails, and it happens that the database is > unstable right now. But the servlet can't know that the database has gone > off-line, because there's no exception, so the servlet just calls the next > method and everything hangs. > > Throwing exceptions instead of printing a message and then swallowing them > would have resulted an app that was easier to test, rather than one that > just timed out but gave no indication to the tester when or why. > > Throw all exceptions, until you get to the user's level, then do something > to make a nice error result. In this case the servlet should have caught > the error, logged it, and then dispatch a nice error page instead of just > hanging forever. > > >> And what would the code in the method that detects the error look like? >> I'm picturing if statements that test the input and then format a message >> if an error is seen. > > > Throw an exception, and format its message for the programmer. Include > all relevant arguments and any relevant internal objects too, even if > private. > > For example, on an array index out of range exception, return the index > value the programmer passed in, so the programmer can see what they did, > and the size of the array that was exceeded, so the programmer can see > what they should have done. > > Let the higher level code decide what message the user should see. > > >> Also, am I correct in thinking that errors of the kind I am describing >> should not be logged, even at a very detailed level, since the log should >> only be for serious things that would involve a system administrator? > > > I log everything. When I'm writing code, I'm normally writing the unit > test at the same time. I crank up the log level to FINER or ALL, put > everything I need to see in log messages, and add a ConsoleHandler so I > can see it easily. Then when it all seems to work, I reduce the log level > but I leave that logging still there. That way all the work I went > through when deciding what to log is not lost, and it's all still there if > I or someone else should need it again. > > Don't ignore optimization: Use "isLoggable(Level)" everywhere and > minimize the places where you have to call it, but don't stint either. > Your time is more valuable that the CPU's. > > This is the true value of "log everything," imo. Having a routine that's > already well instrumented when you need to go back to it and debug > something is a great time-saver in the long run. > > >> Typically, it's because I've made a typo or forgotten the range of >> acceptable values for a parameter to the method. > > > This should always be checked and should throw IllegalArgumentException, > with the messages for the programmer about what the wrong value was and > what range it should of been, as I mention above. > > >> there is not going to be a GUI on which to display the message for that >> error. So how should that be handled? > > > It's OK to wrap the entire main method with a try-catch that results in a > bland "Internal error, please call technical support" message so the user > never sees internal error messages. > > >> Again, I'm assuming that errors like this shouldn't be logged. > > > Log everything. Then, when the user calls technical support, the support > technician can ask the user to email the logs, so tech support can figure > out what went wrong. > > >> 3. Serious errors causes by programmer error. > > > Throw an exception. Let higher level code decide if it wants to log or > propagate the exception. This makes testing much easier. And higher > level code will be more flexible because it decides how the program flows, > not you. At the higher level, log it when you no longer propagate it. > > >> 4. Really bad errors not caused by the programmer. >> >> I assume that ALL such situations should be logged. > > > Throw an exception, let higher level code deal with it. Always log it at > the higher level, and then display an appropriate error message. > > >> What notifications should users receive in such cases? What notifications >> should batch programs make in those cases? > > > Depends on whether your user is technical or not. Technical users might > appreciate the error trace if they have access to your source code. > Non-technical users probably want to call tech support. Log these at the > higher levels of code, throw at the lower levels. Because technical vs. > non-technical might change over the life of the software and you don't > want to have to hunt down every log and throw, just a few at the top > level. > Thank you for your suggestions, Markspace! I'm really attracted to the approach you described since it seems pretty clear and logical to me. But I'm also intimidated by the inevitable backlash that is going to result from your post. I'd just about bet my life that several people will jump in and argue persuasively that various aspects of it are completely wrong and propose a different approach, at least for the parts they dislike and maybe for the whole thing. (And of course some people have already proposed different approaches that are different.) I'm simply not sufficiently experienced with many of these issues to be confident that I will pick the right approach on my own; that's why I ask this kind of question on the newsgroup. I'm hoping a concensus will emerge and then I'll go with that, or at least some version of it. Do you know the saying "A man with one watch always knows what time it is; a man with two (watches) is never quite sure". That's one of my favourites because I've observed that literally on many occasions. I also see it as a metaphor for the situation I'm in: each piece of advice (or "time") comes with an assurance that it is the best but each one has some aspect that someone else disagrees with. So I end up just not knowing which way to proceed. Well, I've been around long enough to know that there won't ever be complete agreement on anything as complex as error handling - there are plenty of different views on routine GUI input errors alone - so I am obviously just going to have to pick the approach that seems most logical to me after a few more people have had their say. I will inevitably have chosen the wrong approach in some people's eyes so I'll just accept that. If I show my code to a prospective employer and he/she takes issue with it, I'll simply tell the truth: I explored options and chose the one that seemed best at the time for my own code. I will assure them that I will do it the way they want for their system if they hire me. I don't see how I can go too far wrong with that approach. Thanks again for your suggestions! -- Rhino
From: Eric Sosman on 29 May 2010 17:25 On 5/29/2010 4:50 PM, Rhino wrote: > "Lew"<noone(a)lewscanon.com> wrote in message > news:htq17k$45n$1(a)news.albasani.net... >> >> Yeah, situations that involve a programmer actually willing to do what it >> takes to learn their craft. Except for those situations, I guess the >> suggestions are pretty useless. > > Oh please! Could YOU pick up a significant amount of detail - either via > memorization or making notes - from a 400 or 500 page book in just a couple > of hours of reading? No. And it's clear that *you* can't, not even with far more time spent studying: May 17, 2010: "I used to know how to [use instanceof] several years ago" Feb 13, 2006[!]: "I've been writing Java code [...] for several years now and feel that I could do a decent job at an intermediate level" Dec 22, 2005[!!]: "I've been writing Java for several years" Dec 6, 2004[!!!]: "I have been writing Java for several years and am fluent enough that I don't have to post questions here very often" [!!!!!!!!] If "several plus five and a half" years of Java experience have left you unaware of instanceof, baffled by the use of interface types, and still asking long-winded elementary questions about exceptions, I'd guess that you will not benefit from any book, however excellent. Something in your brain resists Java, and you'd just be wasting time and money trying to pound square-pegged Java into your head's round hole. Forget Java and take up set design or viola playing or politics or something -- there must be *some* field for which you have more talent, because your talent for Java seems small indeed. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Lew on 29 May 2010 17:38
Daniel Pitts wrote: >>>> You might try your local library or book store. Near where I live, >>>> Borders >>>> is a good place to pick up a book and read it before buying it. Rhino wrote: >>> Thanks for the suggestion though! It would be good in other situations >>> :-) Lew wrote: >> Yeah, situations that involve a programmer actually willing to do what it >> takes to learn their craft. Except for those situations, I guess the >> suggestions are pretty useless. Rhino wrote: > Oh please! Could YOU pick up a significant amount of detail - either via > memorization or making notes - from a 400 or 500 page book in just a couple > of hours of reading? Yes, if that couple of hours is repeated, say, weekly, and accompanied with actual practice in the art. In fact, that pretty much describes how I learn to program Java. I don't spend much money on books at all, so when I do buy it has to really be worth it. I certainly didn't get this good at Java by protecting my ego at the expense of my skill. Nor by making pathetic excuses that somehow not buying books should in any way impede my learning. > Do YOU have so much influence that you can put in a request for an > interlibrary loan and have the book appear in a mere day or two? Maybe a week. And that's just the normal public library, no special influence needed. So? How is never better than a week's delay? > If so, my hat is off to you for you are clearly a superhuman, not a mere > mortal like me. Oh, please! -- Lew |