• Post Reply Bookmark Topic Watch Topic
  • New Topic

Cost of Exceptions  RSS feed

 
TR Smith
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is it costly (CPU time, memory, ...) to create/throw/catch exceptions? I like to design my own exceptions and advertise them in my methods (forcing implementors to catch and do appropriate work). Per (ficticious) example, in a servlet I'll throw a custom exception when a required session variable is not found. Or possibly create an InvalidAccessException and throw at appropriate times. It helps me design by contract (in my interfaces), but wonder if it is draining system resources.

Thanks for any help!
 
Joe Ess
Bartender
Posts: 9406
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a cost associated with setting up a try-catch block, but the cost is miniscule compared to, say, network latency or database access. The cost is a welcome trade-off because with exceptions we can force the programmer to deal with error conditions, which leads to more robust code than say, C, where one can ignore error codes returned by function calls.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Entering a try block is very cheap, as Joe says. Actually throwing an exception, though, is very computationally expensive. The distinction is important. As long as you only throw exceptions to indicate errors, there's no problem. But if you start throwing them to indicate expected conditions, like an alternate return value (and I've seen code where people have done this sort of thing) then your performance will certainly suffer. As long as you use them only to indicate real unexpected conditions, there's no problem.
 
TR Smith
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me add another caveat. What if I have an object (a model in MVC) and it MUST have a name field of 10 characters (max size in the database). Should I validate the length in my set(String name) method (or create a validate method)). This class has the potential to be used in different applications and I really want to enforce it never exceeds 10 chars. Would it be advantageous to create an InvalidName exception and advertise it as being thrown in the setter? It certainly enforces any user accomodates the potential problem (unless they just ignore - ouch). It would also be nice to know why the setter did not work (perhaps it must be unique in the application as well).

Thanks!
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that's fine. Problems could arise in how this was (ab)used, however. If someone wrote code that loaded 10,000 potential names out of a database, then simply tried each one, they'd get a lot of exceptions; this is a lot less efficient than having a validate(name) method they could call. A better solution is to have both -- a validate(name) method, and a constructor or setter that checks validate(name) and throws an exception if it's violated. That way you get the best of both worlds -- the client can avoid the exception if they're knowledgeable, or if not, they get hit with it.
 
TR Smith
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sometimes the best answer is the simplest. I like the implement both methodology and use the best of both worlds. Got bogged down in the "must choose one or anjavascript: x()
jumpingjoyother". Thanks!
 
steve souza
Ranch Hand
Posts: 862
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Entering a try block is very cheap, as Joe says. Actually throwing an exception, though, is very computationally expensive.

Although this may be true, I think developers err on the side of over emphasizing these types of performance concerns. Rarely/never, in real life code is throwing an exception a performance problem. Mostly the question is academic.

Say a web page takes .5 seconds and throws an Exception. The Exception has no substantive/measureable impact on performance. As a previous poster said IO including network/database/file IO are the usual performance culprits. Recently I worked on a program that 95% of application execution time was attributable to query performance.

I have the same response/concerns for such questions as what is faster local/instance/static variables, instance/static methods, HashMaps vs HashTable, a for loop that incremets the counter (i++) or decrements the counter (i--), and all questions of this sort.
[ May 17, 2005: Message edited by: steve souza ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I know, the costs of exception handling have been dramatically reduced in modern JVMs. As almost always, the answer is that you should be much more concerned about the maintainability of the design.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!