The joys of WYTIWYG
I hereby declare that anyone wrapping a wrapped exception should be forced to bend over and prepare to receive the holy instrument as offered by the best Catholic priests to the freshest of young disciples.
How hard is it for apps to ensure that what-you-throw-is-what-you-get? Why oh why do people insist on endlessly wrapping exceptions inside of other exceptions?
Now, I can understand wrapping a low level exception like SQLException in some application specific exception. After all, you don’t want your frontend to be coupled so tightly to your backend and have such intimate awareness of its plumbing.
However, there is quite a difference between doing that and having every single pointless layer add its own wrapper so that by the time the exception finally gets to a layer that decides the buck stops here, you’d have to unwrap it a dozen times to find out what the hell is actually going on. Unless of course you’re a fan of the jbossian school of development, where you just print a stacktrace that will gleefully span 12 medium sized bibles punctuated by the odd ‘root cause:’ message.
This issue is compounded when you have different turdburglars writing each layer. Everyone is hugely nosey, and left to their own devices, people like to know what exceptions have been throw. So not only will said rumpranger wrap the exception throw up to them with their own brand of exception excrement, they’ll also decide that it’s a jolly good idea to see what the exception was, and to log it as WELL as throwing it up.
Needless to say, all it takes is two layers to adopt this crazed brand of genius for your logfiles to lose all meaning and coherency.
For the love of god, do NOT wrap already wrapped exceptions, let them bubble up until someone who cares decides to actually deal with it. Do NOT log an exception if you’re going to pass it along, have some faith in that final recipient, and assuming that they’re likely just as intellectually blessed as you are when it comes to using log.error(ex.getMessage(), ex)
August 24th, 2004 at 5:21 pm
I’ll take a double-wrapped exception any day compared to :
catch (RuntimeException e) {return null;}
Exhibit A
Exhibit B (At least now, it logs, but still returns null :-( )
;-)
August 24th, 2004 at 5:46 pm
throw new ExceptionFacadeDesignPatternException(new AlreadyHandledException(new IWorkForGoogleNowException(new PropertyInfoException(new ControllerException(new LoggedException(new DALException(new WTFException(sqlEx))))))))
August 24th, 2004 at 5:58 pm
i concur. those who log-and-wrap deserve to be force-fed the unmitigated slurry that they have wrought.
August 24th, 2004 at 6:12 pm
If you use a layer that wraps an exception, it’s NONE OF YOU GODDAMN BUSINESS what the original exception was.
Unless, of course, the wrapper exception says “something went wrong inside me” instead of giving useful information to the client app. In that case, the authors should be forced to bend over and prepare to receive the holy instrument as offered by the best Catholic priests to the freshest of young disciples.
August 24th, 2004 at 7:59 pm
Actually,
If you have to troubleshoot a complex problem in a production environment, you will be very thankful for the wrapped exceptions. Yes, they will be verbose, but they will also tell you each layer they were on and how far in that layer they got (from line number matched to the source code).
If you don’t like the verboseness, complain about the top layer logging mechanism, not about intermediate layers preserving information for those desperate times you need it.
Alex. (BEA Support)
August 24th, 2004 at 9:24 pm
I don’t care about exceptions I just think Rick Ross is a blooming asshole.
August 24th, 2004 at 10:12 pm
Alex,
I believe you are confusing stack traces and exceptions… the root cause will include the full stack trace. Craziness!
Perhaps that philosophy is why figuring out Weblogic exceptions is so insanely painful.
August 24th, 2004 at 11:43 pm
Pretty weak one this time, Hani.
August 25th, 2004 at 5:28 am
Wrapping exceptions is not always bad. If you have a layered design, one layer only can tell what went wrong in his layer. The wrapping can add extra context, or sometimes a clear message to the user.
So, as often is the case, the truth is somewhere in the middle.
August 25th, 2004 at 5:36 am
Actually, I do want my frontend to be coupled so tightly to your backend and have such intimate awareness of your plumbing. Well, not yours, Hani.
August 25th, 2004 at 8:45 am
Cox Innate,
YOUR LACK OF RESPECT FOR THE N-TIER ARCHITECTURE IS DISGRACEFUL. A proper J2EE(tm) app will have no knowledge of a database, a webbrowser, a server, a user, or java itself. Everything should be abstracted. Wrapping exceptions is excellent practice is a Sun(tm) Approved Best Practice. Abstracting away the prior exception thrown makes it more robust, scalable, and portable.
Please read up on design patterns and refactor away such thoughts.
August 25th, 2004 at 9:38 am
In C++, friends can touch each other’s privates…
August 25th, 2004 at 10:51 am
After reflecting on this, in Java everyone can touch each other’s privates.
August 25th, 2004 at 1:26 pm
First off, you have to assume that your top-level can unwrap the exceptions and display all the details. Tapestry has done this for four years, so it can’t be that hard.
Tapestry and HiveMind do often wrap exceptions … often to provide more context and to identify important things like the location (not the stack trace, but the file and line containing an error). Often, the underlying service doesn’t have that information when it throws the exception.
Again, this would be a nightmare without true exception reporting, reporting that displays not just the exception message, but also all properties of the exception. Knowing that this is at the top level inverts the normal exception problems (wrapping exceptions obscures useful information) and results in wrapped exceptions providing *more* context without obscuring any.
However, if an exception is thrown with the intent that it be recovered from, rather than merely reported, then its a whole different kettle of fish. In this (IMO rare) case, the a checked exception is appropriate (otherwise, runtime is perfectly good) and the exception should be propagated back through the call stack to some place which can catch it and deal with it.
Certainly, anytime you are using instanceof on a exception, you’ve wandered down the wrong path and deserve the pain you are receiving.
August 25th, 2004 at 5:23 pm
I have a tapestry. My dog pissed on it.
August 26th, 2004 at 2:00 am
>YOUR LACK OF RESPECT FOR THE N-TIER ARCHITECTURE IS DISGRACEFUL. …. Everything should be abstracted.
Ask you self what is the point of that abstraction? As long as you don?t use checked exceptions (and you have no compile time dependency), there is no point.
If one layer throws a RuntimeException it is be course that layer cannot handle a situation. A higher layer should not try to interpret/fix/handle that situation unless it has very intimate knowledge about when the real problem is.
Constant wrapping exceptions only hide what the real problem is. The problem is not the CustomerCannotBeCreatedException or DatabaseIsNotWorkingException but actually an IllegalArgumentException be course a method didn?t except to be called with null.
If any layer tries to fix an “IllegalArgumentException” it will only postpone the problem and course more damage than good.
August 26th, 2004 at 11:28 am
I think this is kinda weak too Hani. I actually don’t mind wrapped exceptions so long as they developer wrapping them knows what they’re doing.
My biggest complaint is when someone wraps the exception, and it says “Could not do X”. Hibernate and JBoss are full of this crap, and it frustraits the hell out of me. I do like Hibernate though…
Anyway, exception chaining is actually very useful if you consider the old way was to just eat the exception and throw a new one.
August 26th, 2004 at 1:19 pm
Do not forget to call fillInStackTrace() if the exception is passing through different tiers.
August 26th, 2004 at 1:51 pm
I used to work with someone who regularly committed code with of the ever so thoughtful:
Catch (Exception e){
}
And, the world will never know what happened.
Luckily, his code was always so perfect that it never threw exceptions….psha!
And, when it did, nobody ever knew about it.
Application errors were always just blamed on the user community.
August 26th, 2004 at 11:49 pm
Sometimes you actually want an exception to be ignored, but often it’s best to at least log that an exception has occurred. Nonetheless, I suspect that the person that worked with the Toy App Maker was developing applications for an ungrateful user community and apathetic management. Therefore, motivation to deliver quality applications was low. This is usually the case in most large corporate environments. In these environments, exception handling takes a back seat to a three hour lunch.
August 27th, 2004 at 9:49 am
fx: After reflecting on this, in Java everyone can touch each other’s privates.
Isn’t that a privileged action thought? ;-)
August 27th, 2004 at 2:05 pm
For those of u wrapping runtime excpetions – bend over now – for Jesus himself will like to use his holy staff (borrowed from Moses) on thee.
Wrapping a checked excpetion is reasonable and an accepted pattern. The idea being that checked exceptions are part of a method’s signature and declaring the checked exception of an internal component would potentially expose your own implementation. Exposing SQLException was a good example.
The problem of course is logging it. Only the deepest leaf exception should ever be logged as part of loggin the stack trace of any given nested exception. Thats right u JBoss, Weblogic, Websphere baffoons… just log ONE fuckin stack trace instead of filling up the damn logs with crap.
And ofcourse, u should never log an exception if ur throwing it, that absolutely does not make any sense and I would like to see them bend over for me as well.
p.s. i will be on vacation soon, Mohammed will be covering my staff obligations during that time.
August 27th, 2004 at 2:07 pm
“…developing applications for an ungrateful user community and apathetic management.”
You mean, like real life? Go figure. I wish I had the resources to run away to flights of fancy–believe me.
August 27th, 2004 at 3:59 pm
The two post that Nick published made me almost shit my pants laughing. return null; and logger.error(“unexpected runtime exception during initialization”, e);.
Dr. Java
Tips for Tricks
August 27th, 2004 at 4:20 pm
I cry everytime I slice through an exception…much like one would with onions except in this case, it’s at those turdburglers for hating me so much as to having gleefully injected their excrement into every layer like they were intent on creating a wonderfully massive turd burrito that they could all dive into with their shit-eating grins, slick bile smeared everywhere having an excrement heyday in my app server which just pukes more and more partially digested feces back at me.
Remember the bile!/Bile forever!
August 27th, 2004 at 4:23 pm
This bile really rolls off the tip of the tongue…thanks Hani.
August 27th, 2004 at 7:34 pm
What pisses me off almost as much as “return null;” is the catch and dont wrap exception pattern! Like:
catch (SQLException e) {
throw new WhoGivesAShitAboutTheCauseStackTraceException(e.getMessage());
}
ArgghhH!
There is just no excuse for not wrapping the cause exception.
If you are not using jdk1.4, there are still plenty of nested exception base classes to allow you to do this in a 1.4 compatible manner. (take you 5 min to write one anyway)
Sadly XAPool is full of this shit. :-(
August 28th, 2004 at 1:50 am
This “wrapping” of exceptions reminds me of a quote:
“If you wrap the crap, it still is going to smell!”
- A Good Friend.
August 28th, 2004 at 10:56 am
“fate”? Excuse me but.., who is this windbag?
August 29th, 2004 at 8:03 pm
The greatest programmer of all time.
Apparently it’s humor.
August 30th, 2004 at 3:29 pm
Why is it that every single time I google “bileblog” it says: did you mean “billabong”? I mean, c’mon man, fu*k that!!
April 12th, 2006 at 11:49 am
billabong … cool.
billabong.