Correct use of exceptions

[tom fredriksen]

Reading a bit more about exceptions.

I am having a bit of problems grappling with the use of checked
exceptions regarding "unexpected" situations. To me all situations which
you write code to handle is expected, so there should not really be many
cases for exceptions at all. So the question for me then, is when to use
exceptions and when not to. Anybody care to share their experiences or
spell out what it is I am missing?

/tom

 

[JPractitioner]

Hello Tom,

IMHO, unexpected things happening in my case would be such as
1. Sudden network connection failure when doing network programming,
i.e. sometimes, before i managed to send all packets, the connection
was closed suddenly due to various factors i.e. bad threading that
caused locks, or even power failure that close the connection
forcefully.

2. people trying to abuse resources, pumping so many data for
buffering.

So when i expect such things, I will throw such and such exception so
that my programs will not be dead.

Thanks.

 

[tom fredriksen]

Hello Tom,

IMHO, unexpected things happening in my case would be such as
1. Sudden network connection failure when doing network programming,
i.e. sometimes, before i managed to send all packets, the connection
was closed suddenly due to various factors i.e. bad threading that
caused locks, or even power failure that close the connection
forcefully.

2. people trying to abuse resources, pumping so many data for
buffering.

This is where my problem is, most of these issues can be resolved
locally at the point of event, f.ex. sudden network connection failure
can be fixed then and there by reopening the connection. Of course, if
its in the middle of a communication, its type decides how you can
handle it. And then its probably legitimate to use exceptions to signal
it up the stack. For example 2 an EOF type buffer is not an exception
but a normal case that happens once in a while, and a full buffer can
possibly be solved by a lockking wait or by increasing the buffer.

Hmm, maybe the solution is to try to solve it locally, but if that does
not work, or the semantics of the failure dictates higher order error
recovery, then you can throw an exception.

/tom

 

[Timo Stamm]

Reading a bit more about exceptions.

I am having a bit of problems grappling with the use of checked
exceptions regarding "unexpected" situations.
To me all situations which
you write code to handle is expected, so there should not really be many
cases for exceptions at all.

Networks and filesystems, for example, are not under your control. For
example, a file you expect to exist may have been deleted while your
program was not running.

That's where you need Exceptions.

Checked exceptions are exceptions that require immediate handling. They
can be useful sometimes to ensure that the API client handles
exceptions, but they are also quite bulky.


Timo

 

[JPractitioner]

tom fredriksen:

For example 2 an EOF type buffer is not an exception
but a normal case that happens once in a while, and a full buffer can
possibly be solved by a lockking wait or by increasing the buffer.

nice

 

[EricF]

This is where my problem is, most of these issues can be resolved
locally at the point of event, f.ex. sudden network connection failure
can be fixed then and there by reopening the connection. Of course, if
its in the middle of a communication, its type decides how you can
handle it. And then its probably legitimate to use exceptions to signal
it up the stack. For example 2 an EOF type buffer is not an exception
but a normal case that happens once in a while, and a full buffer can
possibly be solved by a lockking wait or by increasing the buffer.

Hmm, maybe the solution is to try to solve it locally, but if that does
not work, or the semantics of the failure dictates higher order error
recovery, then you can throw an exception.

/tom

You are not wrong with the network connection failure - a database connection
problem is similar. A common technique is to loop some small number of times
and if you get an exception, sleep a bit. if some threshhold is exceeded, then
throw the exception.

Actually database may be a good example for you if you are familiar with them.
Deadlock can happen but it's rare. That's an exception. Maybe you have a table
of states (if US) and you expect a select to always return 1 row - but someone
has accidentally deleted a row. That's an exception.

Eric

 

[John C. Bollinger]

Reading a bit more about exceptions.

I am having a bit of problems grappling with the use of checked
exceptions regarding "unexpected" situations. To me all situations which
you write code to handle is expected, so there should not really be many
cases for exceptions at all. So the question for me then, is when to use
exceptions and when not to. Anybody care to share their experiences or
spell out what it is I am missing?

I think you are splitting hairs too finely over the meaning of
"unexpected". Perhaps it would help to put down your textbook and read
through some of the platform API documentation for a while to see how
exceptions are used there. Reading the API docs is good for you anyway.
Various classes in java.io and java.util will provide examples that
might help you get the flavor.

 

[Jacob]

I am having a bit of problems grappling with the use of checked
exceptions regarding "unexpected" situations. To me all situations which
you write code to handle is expected, so there should not really be many
cases for exceptions at all. So the question for me then, is when to use
exceptions and when not to. Anybody care to share their experiences or
spell out what it is I am missing?

I think you've got the idea right: Use exceptions sparingly and leave
it for the *exceptional* cases that are outside of your control.

Be aware of the common "Design by Exception" anti-pattern, that may
arise when exceptions are overused.

That said, there are actually quite a number of situations that
are "outside of your control" when you dig in to it, many which are
already elaborated on. The most common entity being "outside of your
control" is your fellow developers, and that's why the most
frequently used exception is the IllegalArgumentException.

 

[no name]

When we talk about exception, it means that in some situation which we think
that it should works this way, but it isn't. For example, when we write
something to connect to remote SMTP server, we assume that the remote server
should be available but actually it is down... In this case, the exception
happened... So we need the exception handling to show our error message to
user and log the error.

Hope this helps!


Guoqi Zheng

http://www.big8reader.com

 

[Roedy Green]

When we talk about exception,

an exception has two features.

1. You can't deal with it easily right where the problem happens, or
you at least potentially might want to deal with it elsewhere at least
inform higher levels.

2. It does not happen that often.

In business, an exception is something you go immediately to your boss
about.

 

[Dimitri Maziuk]

tom fredriksen sez:

Reading a bit more about exceptions.

I am having a bit of problems grappling with the use of checked
exceptions regarding "unexpected" situations. To me all situations which
you write code to handle is expected, so there should not really be many
cases for exceptions at all. So the question for me then, is when to use
exceptions and when not to. Anybody care to share their experiences or
spell out what it is I am missing?

You are not missing anything: Java's taking cheked exceptions
way too far. As in throwing exceptions in situations that are
not exceptional where a simple boolean test would do the job
without exception overhead.

Dima