Re: Why no "cause" constructors for NumberFormatException

From:

Patricia Shanahan <pats@acm.org>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 10 Jul 2007 09:08:19 -0700

Message-ID:

<f70atl$10h5$1@ihnp4.ucsd.edu>

dvdavins@pobox.com wrote:

On Jul 10, 11:14 am, Lew <l...@lewscanon.nospam> wrote:

Lew wrote:

This all begs the questions of why you're rethrowing the exception (or one
based on it) instead of logging and handling it, and why you need a different
message if you haven't handled the Exception, and why you have to throw
NumberFormatException instead of a custom application-specific (possibly
checked) Exception since you aren't handling it at first catch, and why you
are accepting possibly invalid number formats for conversion instead of
prevalidating them in the first place, for all of which we will stipulate that
you have good reasons for bucking the best-practices trend. For others
reading this thread, these questions might be relevant.

The exception is being thrwon as a direct resulot of bad user input,
that so far is coming from a command line. If this program evloves so
that it's ever used by more than my friends, I'll have other ways to
enter what anmunt to environment variables. In the mean time, I want
to give the users meaningful feedback in the console.

I've had similar situations, but the new exception was derived from a
special ValidationException that I used if, and only if, the exception
was caused by bad user input. That affected how the exception was
reported at the user interface layer.

Patricia