try/catch
in [Java Programming]
|
Next: localhost:9080
From: dmcreyno on 14 Sep 2005 10:15 I hate to bring this up again, but someone is trying to get me to do something I wouldn't normally do. I am being told keep all try blocks to a bare minimum in size. This is leading to methods that have lots of small try/catch constructs sprinkled about. IMHO, it makes the code bulky and less readable than having a try/catch with a handful of catch clauses. While I have abstained from following this advice so far, others are creating ugly methods that we all end up having to maintain. 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.
From: jan V on 14 Sep 2005 10:47 > 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.
From: Thomas Hawtin on 14 Sep 2005 10:49 dmcreyno wrote: > > I am being told keep all try blocks to a bare minimum in size. This is You could put the body of the try statement in a different method. Then the try block would be really small. To me this tends to suggest that some symptom (possibly imagined) is trying to be fixed rather than the cause. Perhaps the code mixes responsibilities, and that if separated them out then a particular exception would be limited to only the relevant code. > 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. Java exceptions are generally implemented very differently from C++. Because there are no automatic object to destruct, the number of (implicit) catch blocks is small (mostly from synchronized). When an exception is thrown the JVM looks through where the program counter was for each stack frame. In C++ by contrast, generally, code is produced to maintain a linked list of destructors. This cost is incurred whether or not the exception is thrown. So the cost or try blocks in Java is non-zero, but very small. Tom Hawtin -- Unemployed English Java programmer http://jroller.com/page/tackline/
From: Robert Klemme on 14 Sep 2005 11:04 dmcreyno wrote: > I hate to bring this up again, but someone is trying to get me to do > something I wouldn't normally do. > > I am being told keep all try blocks to a bare minimum in size. This is > leading to methods that have lots of small try/catch constructs > sprinkled about. IMHO, it makes the code bulky and less readable than > having a try/catch with a handful of catch clauses. While I have > abstained from following this advice so far, others are creating ugly > methods that we all end up having to maintain. > > 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. Completely agree. The only other thing that comes to mind is that you can do error handling with finer granularity. However to me this would indicate that some refactoring was in order. Kind regards robert
From: Chris Smith on 14 Sep 2005 11:05
dmcreyno <david.mcreynolds(a)gmail.com> wrote: > 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. Regarding performance: It is possible that performance would be improved by using smaller try blocks, but it's far from a sure bet. The reason performance might be improved is that the control flow diagram is simpler, which means that the JIT may perform more optimizations more easily. For checked exceptions, this is unlikely to make any difference... but for unchecked exceptions (and NullPointerException in particular) it may be significant. 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. That would hurt performance for the small-try approach. It's possible, but not likely. Other: 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. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation |