Why no "cause" constructors for NumberFormatException

D

dvdavins

IllegalArgumentException implements the (relatively) new contructors
that include a Trhowable as a "cause". But NumberFormatException,
which extends IllegalArgumentException, does not. Anybody know why?
 
R

Roedy Green

IllegalArgumentException implements the (relatively) new contructors
that include a Trhowable as a "cause". But NumberFormatException,
which extends IllegalArgumentException, does not. Anybody know why?

See
file://localhost/E:/program%20files/Java/jdk1.6.0_01/docs/api/java/lang/NumberFormatException.html#NumberFormatException(java.lang.String)

You can pass a "cause" string.
 
T

Twisted

IllegalArgumentException implements the (relatively) new contructors
that include a Trhowable as a "cause". But NumberFormatException,
which extends IllegalArgumentException, does not. Anybody know why?

I guess they forgot it, or just haven't gotten around to it yet.
Submit it to Sun's bug tracker and they'll probably have it in Java 7.
 
L

Lew

IllegalArgumentException implements the (relatively) new contructors
that include a Trhowable as a "cause". But NumberFormatException,
which extends IllegalArgumentException, does not. Anybody know why?
[/QUOTE]
Roedy said:
You can pass a "cause" string.

You can also call initCause(), can't you?
 
P

Patricia Shanahan

Twisted said:
I guess they forgot it, or just haven't gotten around to it yet.
Submit it to Sun's bug tracker and they'll probably have it in Java 7.

I'm not so sure of that. Does a Throwable cause really make sense, given
the definition of NumberFormatException?

Patricia
 
D

dvdavins

I'm not so sure of that. Does a Throwable cause really make sense, given
the definition of NumberFormatException?

Yes. For instance, since you can't set the message, the only way to
effectively do so is to catch the oroginal NumberFormatException and
to throw a new one with the message that's needed. It would be good to
then include the original as the cause. (Better, IMO, would be to be
able to set the message directly, but that's a broader issue with
Throwable.)
 
P

Piotr Kobzda

Twisted said:
I guess they forgot it, or just haven't gotten around to it yet.
Submit it to Sun's bug tracker and they'll probably have it in Java 7.

That could be RFE at best, not a bug report.

Quote from Throwable Javadoc:

"Further, as of release 1.4, many general purpose Throwable classes
(for example Exception, RuntimeException, Error) have been retrofitted
with constructors that take a cause. This was not strictly necessary,
due to the existence of the initCause method, but it is more convenient
and expressive to delegate to a constructor that takes a cause."

More there:
http://java.sun.com/javase/6/docs/api/java/lang/Throwable.html


Just to summarize that, the solution for the OP's problem (already
mentioned also by Lew in this thread) seems to be:

...
} catch (NumberFormatException e) {
throw (NumberFormatException)
new NumberFormatException("new message").initCause(e);
}


piotr
 
L

Lew

Yes. For instance, since you can't set the message, the only way to
effectively do so is to catch the oroginal NumberFormatException and
to throw a new one with the message that's needed. It would be good to
then include the original as the cause. (Better, IMO, would be to be
able to set the message directly, but that's a broader issue with
Throwable.)

Didn't the suggestion to use initCause() help?
You can also call initCause(), can't you?

<http://java.sun.com/javase/6/docs/api/java/lang/Throwable.html#initCause(java.lang.Throwable)>
 
L

Lew

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.
 
D

dvdavins

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.
 
P

Patricia Shanahan

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
 
T

Twisted

I'm not so sure of that. Does a Throwable cause really make sense, given
the definition of NumberFormatException?

Is it our place as programmers to question the users when they say
they desire a feature? Or just to implement it?

In any event, the OP explained elsewhere that they wanted to wrap some
RuntimeExceptions whose construction isn't under their control with
copies that add a detail message. I suppose they *could* wrap them in
a different exception type, but really, should they be *forced* to?
The fact that they can use "initCause" suggests the answer to that is
no, since they aren't in fact forced to. Instead they just have to
jump through extra hoops to throw the exception they want to throw,
which appears to benefit nobody.
 
P

Patricia Shanahan

Twisted wrote:
....
Is it our place as programmers to question the users when they say
they desire a feature? Or just to implement it?
....

I'm a student, so it is definitely my place to question things. However,
I've been asking questions about computer programming for 40 years, and
see no reason to stop now.

Implementing every requested feature, without questioning the tradeoffs
involved, would be an absolute disaster for future maintainability of
any computer program or programming language.

Patricia
 
T

Twisted

Implementing every requested feature, without questioning the tradeoffs
involved, would be an absolute disaster for future maintainability of
any computer program or programming language.

One could argue that it's the user's own darn fault for requesting so
many features if the system then becomes a feeping creature. :)

More significantly, in this specific case we're talking about adding
one constructor to one library class, hardly a major change or
complication of the language. In fact, if all of the standard
exception classes had the same pattern of constructors, it would
amount to a *simplification*. Right now they are evidently not 100%
consistent with one another, and it's causing at least one user a spot
of awkwardness.
 
T

Twisted


You can if you write "throw new NumberFormatException(...)" into your
code. This is exactly what the OP is doing; they got a
NumberFormatException tossed up from code that isn't theirs (or even
from the VM, though I think that's unlikely with this particular
exception, unlike say ArithmeticException) and want their own code to
then emit a NumberFormatException with the detail message of their
choice. The only way to do that is to throw a new one, and the best
practise when throwing a new exception because of an old exception is
to wrap the old exception as the "cause" of the new one... Of course,
if they'd only included an "initDescription" as well as "initCause" in
Throwable, he could just change the detail message of the preexisting
exception and rethrow it...
 
P

Patricia Shanahan

Twisted said:
One could argue that it's the user's own darn fault for requesting so
many features if the system then becomes a feeping creature. :)

The problem is that most useful systems have more than one user. Any one
user may have a couple of enhancement ideas each of which would be a
good thing. A few thousand users may have thousands of ideas.

Even assuming a single user, someone has to make the cost benefit
trade-off. If the user is going to make the trade-off, they need to be
informed of the costs before making their final decision. Again, the
change should not be made just because it has been requested, without
some discussion of the reasons for not doing it.
More significantly, in this specific case we're talking about adding
one constructor to one library class, hardly a major change or
complication of the language. In fact, if all of the standard
exception classes had the same pattern of constructors, it would
amount to a *simplification*. Right now they are evidently not 100%
consistent with one another, and it's causing at least one user a spot
of awkwardness.

The particular change under discussion indeed seems far more reasonable
than suggestion that all requested changes should be implemented without
even questioning their usefulness.

Patricia
 
R

Roedy Green

Implementing every requested feature, without questioning the tradeoffs
involved, would be an absolute disaster for future maintainability of
any computer program or programming language.

It is the programmer's (designer's) job to glean from the users'
request just what the problem is he is having and come up with a
solution.

The users have no clue HOW the problem is best solved.

I find it highly useful for a programmer to actually USE the code in
production over a day or two as a humble clerk. He will see all kinds
of opportunities for improvement a naive user would not think to ask
for.

I remember doing a banking system back in the 70s. The users were
asking for all kinds of things that were extremely hard for computers
to do but were easy for humans. The users were asking for what they
thought would be EASY, not useful. The were astounded to learn that
it is trivially easy to maintain lists is several different orders at
once. They never dreamed of asking for the "impossible".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top