Exceptions no longer incur overhead?

[Guest]

One of our classes has a method to look up an object. If the object
does not exist, it throws an exception to indicate that. I thought it
would be better to just return null, as exceptions incur overhead. I
talked to the senior java developer who wrote the class, and he said
that recent versions of Java have improved exceptions to the point
that they do not really incur any overhead. Is this true?

 

[Mike Schilling]

One of our classes has a method to look up an object. If the object
does not exist, it throws an exception to indicate that. I thought it
would be better to just return null, as exceptions incur overhead. I
talked to the senior java developer who wrote the class, and he said
that recent versions of Java have improved exceptions to the point
that they do not really incur any overhead. Is this true?

It's not really the right question. It's better to ask:

Is the object's nonexistence an exceptional condition?

If code calling the lookup method has to anticipate and deal with the fact
that the object doesn't exist, then null (or some other distinguihsed value)
should be returned. It makes no sense to force clients to write code like

Data value = null;
try
{
value = cache.lookup(key);
}
catch (NoSuchObjectException ex)
{
value = new Data();
cache.add(key, data);
}

On the other hand, if the object always should exist, and its nonexistence
is dealt with by error-handling code, it makes more sense to throw the
exception directly in the lookup method, rather than to force clients to
write code like:

Data a = cache.lookup(key1)
if (a == null)
{
log ("no such object " + key1);
return false;
}
Data b = cache.lookup(key2)
{
log ("no such object " + key2);
return false;
}
etc.

As is often true, performance isn't the only issue here.

 

[Tom Hawtin]

One of our classes has a method to look up an object. If the object
does not exist, it throws an exception to indicate that. I thought it
would be better to just return null, as exceptions incur overhead. I
talked to the senior java developer who wrote the class, and he said
that recent versions of Java have improved exceptions to the point
that they do not really incur any overhead. Is this true?

In some circumstances exceptions *throws* can be optimised away.
Explicitly creating an exception, however, is expensive. Mostly in
creating the stack trace.

Anyway, the general approach is to write code to be well written. Then
test performance in real world situations.

Tom Hawtin

 

[Mark Rafn]

One of our classes has a method to look up an object. If the object
does not exist, it throws an exception to indicate that. I thought it
would be better to just return null, as exceptions incur overhead.

Like most micro-optimization, this should take a backseat to clarity and ease
of understanding. What are the semantics that best fit your use cases?

Exceptions are nice because they indicate exceptional cases, and you can
declare them to make them explicit, and they're easy to bubble up to the
appropriate handling level.

Null returns are nice because they fit the developer's mental model of
many types of find operations, but you have to document and hope callers
will understand what it means.

Performance is a secondary (or later) consideration.

I talked to the senior java developer who wrote the class, and he said
that recent versions of Java have improved exceptions to the point
that they do not really incur any overhead. Is this true?

Exception declarations incur very little overhead. Just having a
try/catch structure in your code used to be somewhat slower than code
without it, but that's not true in modern VMs. Actually throwing an
exception is a little slower than other return types.

But nothing costs as much as an API that doesn't fit the usage patterns.

 

[Matthias Buelow]

One of our classes has a method to look up an object. If the object
does not exist, it throws an exception to indicate that.

Just for clarity, a negative search is not an exceptional condition but
a permissible result, so it's probably better to return null.

 

[Roedy Green]

talked to the senior java developer who wrote the class, and he said
that recent versions of Java have improved exceptions to the point
that they do not really incur any overhead. Is this true?

There are inherently heavy overhead beasts since they have to chase
back up the call stack (dynamically constructed) looking for a
suitable handler. In principle, they have to do an instanceof on all
the handlers all the way back. Each handler may be nested several
inheritance classes deep.

However exceptions are for exceptional conditions, so that overhead is
not important. You don't use them to pass data back from a method.

 

[Bjorn Borud]

["Mike Schilling" <[email protected]>]
|
| It's not really the right question. It's better to ask:
|
| Is the object's nonexistence an exceptional condition?

that's very good advice.

I'd also like to add that one should prioritize correctness and
usability before low-level performance considerations. most of the
time, these sort of decisions are not going to have a major impact on
performance -- usually choice of algorithms and data structures as
well as the overall approach to a problem has orders of a magnitude
higher impact.

there's also an additional piece of advice. if, for instance your
method returns a collection or an array, if it makes sense, you can
return an empty array or collection. sometimes this leads to really
simple code.

-Bjørn