 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006Question about Exception behaviour
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 > 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 >> 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 [quoted text clipped - 3 lines] > 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 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 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 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 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. > 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 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.