try/catch
in [Java Programming]
|
Next: localhost:9080
From: Robert Klemme on 14 Sep 2005 11:17 Chris Smith wrote: > dmcreyno <david.mcreynolds(a)gmail.com> wrote: > There is, though, a much more significant concern that tends to keep > try blocks small, and it has nothing to do with performance. A catch > clause is written to handle a specific logical error. For some common > exceptions, the same exception class may be thrown in several places, > each of which is logically a *different* error condition. I can't > tell you how many times I've debugged error cases in code, and found > that a catch block was assuming problem A, when really problem B > occurred. In most such cases, problem B wasn't even anticipated. > The answer here is to keep try blocks short and include only minimum > code that can throw the exception for the error condition you expect. Inspite of this I'd still rather have rather few try-catch per method. For one, most of the time you catch only checked exceptions. And the whole idea of exception handling (apart from the stack unwinding etc.) is to have centralized error management (as opposed to checking the return status of every method). It depends on the application of course but IMHO genereally fewer catch blocks are better. My 0.02 EUR... robert
From: dmcreyno on 14 Sep 2005 11:30 Chris Smith wrote: <snip> > > There is, though, a much more significant concern that tends to keep try > blocks small, and it has nothing to do with performance. A catch clause > is written to handle a specific logical error. For some common > exceptions, the same exception class may be thrown in several places, > each of which is logically a *different* error condition. I can't tell > you how many times I've debugged error cases in code, and found that a > catch block was assuming problem A, when really problem B occurred. In > most such cases, problem B wasn't even anticipated. The answer here is > to keep try blocks short and include only minimum code that can throw > the exception for the error condition you expect. > I see and agree with your point. That being said, unfortunately this is pretty much all Struts action related and all the try/catches are doing the same thing since the only checked exceptions at this level are custom application specific and they only have one exception the business tier is allowed to throw. However, I would definitely take this advice to heart in the business and backend tiers where we might encounter many different exceptions.
From: jan V on 14 Sep 2005 14:45 > On the other hand, as you mention, it's possible that the JIT is > choosing an implementation of try/catch that requires work when > entering/exiting a try block. Sorry to be picky about this, but can you give any evidence that any production JVM does anything on entering or leaving a try block (within a try-catch context, not a try-finally)? Last time I poured over class file disassemblies, I noticed a distinct lack of any logic whatsoever inserted by the compiler to deal with *entering* a try block. To me this suggests that try blocks, of themselves, do not impose any performance hit whatsoever. My understanding of this stems from looking at classes many years ago.. maybe things have changed since then, in which case I'd like to see some evidence of this. If you can point me to any JVM instruction supporting your claim, that would be enough. ;-)
From: Joan on 14 Sep 2005 14:56 "jan V" <nul(a)nul.be> wrote in message news:JJWVe.193818$FO4.10598453(a)phobos.telenet-ops.be... >> No one seems to be able to articulate exactly what problem is >> being >> solved, just some vague references to performance which I find >> counter >> intuitive. If a try clause causes the compiler to create a >> "protected" >> section of code then more "trys" will lead to more "protected" >> sections >> (protected: stack trace maintenance) and that souldn't be a >> good thing. > > My understanding of try-catch performance penalties is that the > generated > code does not impose any runtime penalty if the try block > completes normally > (there is no JVM code or "awareness" of entering a block, even > a try block). > Only if an exception is thrown does the JVM have to do a bit of > extra work > (with the emphasis on "a bit of"). > > I'm afraid you're not alone by being told how to do things by > people who > can't substantiate their reasons for doing it this or that way. > When that > happens to me, I keep an internal counter of the number of such > instances. > When the counter reaches an arbitrary psychological limit, I > walk out of the > door and leave such teams to fend for themselves. Isn't this the kind of behaviour that gives programmers a bad name? If your spouse asks you to get a carton of milk on the way home from work do you insist s/he substantiate his/her reason? Or I suppose you don't say anything for 6 months and then walk out. > >
From: Sanjay on 14 Sep 2005 15:15
Well I just wanted to add another point here. With whatever I have read, I think the real performance hit would be (if at all it is substantial), could be when the exception is thrown. I have seen lot of code where custom exeptions are thrown as a good programming practice. This could be a performance hit since VM has to gather the stack trace information. So we can do some optimization by not throwing a newly created object,but by throwing a common static object. In this case there wont be any stack trace produced. But beware this could be a problem while debugging the exception. |