Error Handling
in [Java Help]
|
From: Daniel Pitts on 28 May 2010 17:23 On 5/28/2010 1:51 PM, Rhino wrote: > "Jeff Higgins"<oohiggins(a)yahoo.com> wrote in message > news:htp86q$arf$1(a)news.eternal-september.org... >> On 5/28/2010 2:58 PM, Rhino wrote: >>> I'm trying to figure out some "best practices" for error handling. >>> >> <http://books.google.com/books?id=Fz1kQgAACAAJ&dq=Robust+Java&cd=1> > > Thank you. Money is tight right now so I won't be able to get that book > right away but I'll look at buying it when I have a bit more disposable > income.... > > -- > Rhino > > 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. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Jeff Higgins on 28 May 2010 18:17 On 5/28/2010 5:23 PM, Daniel Pitts wrote: > On 5/28/2010 1:51 PM, Rhino wrote: >> "Jeff Higgins"<oohiggins(a)yahoo.com> wrote in message >> news:htp86q$arf$1(a)news.eternal-september.org... >>> On 5/28/2010 2:58 PM, Rhino wrote: >>>> I'm trying to figure out some "best practices" for error handling. >>>> >>> <http://books.google.com/books?id=Fz1kQgAACAAJ&dq=Robust+Java&cd=1> >> >> Thank you. Money is tight right now so I won't be able to get that book >> right away but I'll look at buying it when I have a bit more disposable >> income.... >> >> -- >> Rhino >> >> > 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. > My local public library is very good about inter-library loans. If the book can be obtained from within the state there is no charge for postage. Unfortunately I've lived in regions where support for ILL was not so good.
From: Jeff Higgins on 28 May 2010 19:03 On 5/28/2010 2:58 PM, Rhino wrote: > 1. User input errors in a GUI. > > The user has a form or panel in front of him and is asked to enter his date > of birth; despite help screens and labels advising him that the format is > year-month-day separated by dashes, e.g. 2010-05-28, he enters this > information incorrectly, e.g. 05/28/10. The code that validates the input on > the form detects this error. How should the user be notified of this error? > I'm picturing a utility class being invoked by the GUI to validate the date > since this kind of validation is going to be very routine. Obviously, the > utility method is going to format an error message that tells the user what > is wrong (in the appropriate language) but then what? > <http://java.sun.com/javase/6/docs/api/javax/swing/JFormattedTextField.html> <http://java.sun.com/docs/books/tutorial/uiswing/components/formattedtextfield.html>
From: Jeff Higgins on 28 May 2010 19:10 On 5/28/2010 7:03 PM, Jeff Higgins wrote: > On 5/28/2010 2:58 PM, Rhino wrote: > >> 1. User input errors in a GUI. >> >> The user has a form or panel in front of him and is asked to enter his >> date >> of birth; despite help screens and labels advising him that the format is >> year-month-day separated by dashes, e.g. 2010-05-28, he enters this >> information incorrectly, e.g. 05/28/10. The code that validates the >> input on >> the form detects this error. How should the user be notified of this >> error? >> I'm picturing a utility class being invoked by the GUI to validate the >> date >> since this kind of validation is going to be very routine. Obviously, the >> utility method is going to format an error message that tells the user >> what >> is wrong (in the appropriate language) but then what? >> > > <http://java.sun.com/javase/6/docs/api/javax/swing/JFormattedTextField.html> > > <http://java.sun.com/docs/books/tutorial/uiswing/components/formattedtextfield.html> > > <http://java.sun.com/products/jlf/ed2/book/>
From: Arved Sandstrom on 28 May 2010 19:27
Rhino wrote: > I'm trying to figure out some "best practices" for error handling. > > 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 > exceptions are a reasonable approach to some input errors but that seems to > be the minority opinion; most people prefer other ways. > > I'm trying to understand what the best approach is for a few different > situations. > > 1. User input errors in a GUI. > > The user has a form or panel in front of him and is asked to enter his date > of birth; despite help screens and labels advising him that the format is > year-month-day separated by dashes, e.g. 2010-05-28, he enters this > information incorrectly, e.g. 05/28/10. The code that validates the input on > the form detects this error. How should the user be notified of this error? > I'm picturing a utility class being invoked by the GUI to validate the date > since this kind of validation is going to be very routine. Obviously, the > utility method is going to format an error message that tells the user what > is wrong (in the appropriate language) but then what? Be aware (you may already be) that if the GUI is a web application GUI, that the odds are pretty good that much of the validation will be handled by a framework. For example, the scenario you posit is indeed so routine that built-in mechanisms in many web frameworks will handle this without any Java coding on your part being required at all...you just have to designate in web pages which input elements need this kind of date format conversion. > 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 > panel or just below it. Often, you would flag the particular input field > that is in error. This feels rather 'old school' at this point but the basic > design is tried and true and it worked pretty well. This "old school" approach is the one that works best, IMHO. You have several different types of input problems: 1. A single input element - usually the error message is displayed right by the offending input element; 2. A group of input elements - you have a bit more freedom as to where to place the error message; using the page top as a standard location for more general error messages is not uncommon. > I've seen, written, or used programs where an error message popped up on in > its own window, advising the user what the error is. (Of course, this > approach needs a bit of care since you want to make sure that the message > isn't modal so that the user can see the message but also the input field so > that he can grasp the error. And you want the error window to be movable so > that it isn't frozen in one position and covering the input field that is in > error.) > > Which of these do very experienced Java developers prefer? Or is there a > different approach that is better than these? 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 don't myself use dialogs/popups for errors; I use these for normal workflow and only where it makes sense. I keep errors to same page messages or standard error pages. > 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. But what actually gets returned to the calling class? > Presumably, the method that edits the date was going to return a boolean > indicating if the data is good or not but how does the error message get > back to the caller? (At one point, I was writing edits like this to return > an array of Objects; the array always started with the boolean that says if > the data was good or not and, if the data was bad, the second Object would > be an error message. If the data was good though, only the boolean was > returned. Is that a good or bad design? It _felt_ wrong and forced the > calling class to parse the array but it worked okay.) See above - in a web application environment your framework will handle these low level details. Often you won't need any code at all. Even where you do (for more elaborate validation possibly involving a number of inputs plus the business context) you often don't have to do more than supply just a validation method, and possibly a custom message in a properties file, and hook it into the framework. > 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'm > tempted to argue that the log _could_ be a place where user errors get > recorded so that people managing the users know which of their people are > having a lot of errors so that remedial training might be provided but I > suspect you will persuade me that that kind of requirement should be handled > differently.) > [ SNIP ] I wouldn't myself log a user input validation error, since there is no error from the application standpoint. AHS |