Error Handling
in [Java Help]
|
From: Rhino on 28 May 2010 20:28 "Daniel Pitts" <newsgroup.spamfilter(a)virtualinfinity.net> wrote in message news:LvWLn.15255$7d5.3812(a)newsfe17.iad... > 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. > 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. Thanks for the suggestion though! It would be good in other situations :-) -- Rhino
From: Rhino on 28 May 2010 20:31 "Jeff Higgins" <oohiggins(a)yahoo.com> wrote in message news:htpffj$dbh$1(a)news.eternal-september.org... > 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. We have ILL loans at our local library. I don't recall ever having had one but I know they are available. I've heard it can take many weeks for the book to materialize though so that doesn't do me much good today ;-) And I've still got the challenge of either memorizing or summarizing large quantities of information before the book has to be returned. I've got more time to do it but still.... If the book is as good as the reviews look, I think I need to buy it. -- Rhino
From: Rhino on 28 May 2010 20:34 "Jeff Higgins" <oohiggins(a)yahoo.com> wrote in message news:htpihp$qip$1(a)news.eternal-september.org... > 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/> > All of those are excellent suggestions for input fields in GUIs. If you can build the editing right into the field, you don't have to show the sort of error messages we used to show in the mainframe/dumb terminal days. Thanks for reminding me about those! -- Rhino
From: Rhino on 28 May 2010 20:37 > > 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. > Thanks for talking about these errors from the perspective of frameworks. I didn't want to lose sight of that whole class of applications, even if it is not my focus today! I haven't used any frameworks per se but I have heard some intriguing things about them and definitely want to work with them when I get a chance.... -- Rhino
From: Lew on 28 May 2010 23:21
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. -- Lew |