Question about Exception behaviour

[poisonrain0]

Hey!

The scenario:

We have chained exceptions, that is when an exception is caught we
throw our own exception. which in turn may be caught else where and
some other exception may be thrown. in one such case we got a stack
trace that ended with a NullPointerException but there was no
cause/message following this... we have not coded any class in anyway
that any exception gets truncated. atleast if they are truncated it is
meaningfully reduced, so that pertinent information is left untouched.

The Query:

This makes me ask if it possible for any person to set the message in
the throwable class to null or an empty message? it would be meaning
less but none the less is it possible?


The snapshot of the exception...

at
cz.unicorn.afu_v1.af_v1.busc_v1.bdo_v1.BDOProxy.getBRO(BDOProxy.java:375)
at
cz.unicorn.afu_v1.af_v1.busc_v1.bdo_v1.BDOProxy.invoke(BDOProxy.java:114)
... 118 more
Caused by: java.lang.NullPointerException

Thank You,
-U

 

[Chris Uppal]

This makes me ask if it possible for any person to set the message in
the throwable class to null or an empty message? it would be meaning
less but none the less is it possible?

It is apparently possible to pass null to the constructor of a Throwable as
either or both of the message or the chained exception. At least the code has
no obvious checks against doing so.

Also it is possible to throw null.
IllegalStateException e = null.
throw e;
Which produces odd results in a stack trace ;-)

-- chris

 

[Robert Klemme]

It is apparently possible to pass null to the constructor of a
Throwable as either or both of the message or the chained exception.
At least the code has no obvious checks against doing so.

In fact I've never seen a NPE coming from the JVM or std lib carry a
message. NPE is pretty much self explanatory, isn't it?

Also it is possible to throw null.
IllegalStateException e = null.
throw e;
Which produces odd results in a stack trace ;-)

robert

 

[poisonrain0]

Hi Chris,
So you are saying that in class Throwable (as i can see it too) it
allows one to set the message and the cause to null, hmmm!

well, here is the stinger... even if it DOES produce odd results in the
stack trace it does have the information of a line of two after it...

Example:
cz.unicorn.afu_v1.af_v1.util_v1.date_v1.test.TestException
at
cz.unicorn.afu_v1.af_v1.util_v1.date_v1.test.ExceptionChainingTest.topLink(ExceptionChainingTest.java:29)
at
cz.unicorn.afu_v1.af_v1.util_v1.date_v1.test.ExceptionChainingTest.main(ExceptionChainingTest.java:19)

BUT if you see the earlier example the last line of the trace is JUST a


"Caused by: java.lang.NullPointerException"
which is very strange... meaning it just appeared with the stack frames
being empty !!

any more ideas...

-U

 

[poisonrain0]

Hey Robert,
Yes NPE is pretty much self-explanatory, but one would like to know
where this NPE originated at? without which the NPE being thrown is of
not much use to us, is it?

as you can see below... there is a point to caused by NPE but it
doesnt tell us where at or from...???

at
cz.unicorn.afu_v1.af_v1.busc_v1.bdo_v1.BDOProxy.getBRO(BDOProxy.java:375)

at
cz.unicorn.afu_v1.af_v1.busc_v1.bdo_v1.BDOProxy.invoke(BDOProxy.java:114)

... 118 more
Caused by: java.lang.NullPointerException




-U

 

[poisonrain0]

EUREKA!!!
e.setStackTrace(new java.lang.StackTraceElement[0])
use this and you get a Caused by with nothing after it...

why on earth would anyone be so masochistic ???
-U

 

[Optional]

It looks to me that you got caught by poor design. Why chain
exceptions? If is a checked exception declare it in the throws and let
the proper method (See: Design By Responsiblity) in the stack handle
it. If it an unchecked exception (like NPE), some ultimate authority
(main route, servlet, etc) needs to catch it and handle it. Its much
simpler and causes a lot let head scratching.

 

[Oliver Wong]

It looks to me that you got caught by poor design. Why chain
exceptions? If is a checked exception declare it in the throws and let
the proper method (See: Design By Responsiblity) in the stack handle
it. If it an unchecked exception (like NPE), some ultimate authority
(main route, servlet, etc) needs to catch it and handle it. Its much
simpler and causes a lot let head scratching.

To be fair, I've seen some situations in which exception chaining (in my
humble opinion) made sense. You might have a tiered plugin design, for
example, where each plugin catches all the exceptions of their children
plugins, tries to recover from them if possible, but otherwise wraps the
exception and rethrows it, so that a parent plugin can try to handle it. A
lot of Eclipse is built that way.

Another example is when you know that a given exception thrown from a
given 3rd party library means something specific, and you'd like to add that
specific information to whatever is higher up in the callstack (which may
possibly be the end user). Perhaps your 3rd party library FrotzBlaster
throws a NullPointerException when passed a FrotzReferer that doesn't point
to a Frotz that actually exists on the Network, but finding out whether the
Frotz exists or not is expensive and has various side effects. So you read
in the "Frotz=fred" line from the configuration file, but you don't actually
validate the Frotz until the user request it to be blasted. When the user
DOES request it to be blaster, you pass the Frotz over to the library, which
then throws a NPE. You catch it, and wrap it in an different exception which
actually explains that the source of the error is an incorrect setting in
the configuration file.

- Oliver

 

[jladd]

Good comments Oliver.
Chaned exceptions make sense.

Now using Exceptions to control program flow that could have been
handled by a conditional statement, thats just wrong.
I know this wasnt mentioned in the above posts but I think its an
important enough practice that it warranted mentioning.

Rgs, James.
http://www.jamesladdcode.com/moat