throwing an exception from an exception handler

  • Thread starter Thread starter Julie
  • Start date Start date
J

Julie

What should happen if you catch an exception and from that exception
handling code call a method which itself generates an exception that
gets caught? Is this sort of thing acceptable? Will the second
exception get caught? It seems like it should but I'm not absolutely
sure.

I have some code that crashed because of an exception not getting
caught, and I am trying to determine how this could have happened,
since I have "try/catch Exception" around all of my threads.

My "catch Exception" statements log the exception to a file; however,
I noticed that this logging code was not thread safe. So, it seems
quite possible that in handling an exception, a second exception would
be generated when the thread was attempting to simultaneously access
the log file at the same time as another thread.

Thoughts?
 
It depends. But there's not any reason that throwing an exception from a
"catch" clause is in and of itself a problem.

An exception might be thrown from a "catch" clause for a variety of
reasons, including that the exception is not actually being handled, but
rather is being logged and rethrown, or being wrapped in a more-descriptive
exception, or is a legitimate failure of an attempt to handle the original
exception, or any number of other similar reasons.

What's _not_ acceptable is for an exception to be thrown, from a "catch"
clause or elsewhere, due simply to a program bug.  If that happens, you
need to fix the bug instead of worrying about whether the bug caused an
exception to be thrown from a "catch" clause or not.


In general: you should only catch exceptions that a) you expect to happen,
and b) that you know how to safely recover from.

An exception to this (sorry, no pun intended) is a catch-all handler at the
top of a thread that simply logs the exception before terminating the
process (or thread, if it's isolated enough for that to suffice).



If the code is not thread safe but is used in a multi-thread scenario, then
the answer is to fix the code so that it's thread safe.  The question about
whether it's okay to throw an exception from a "catch" clause is a red
herring.

Pete
Click to expand...

So, I totally agree that ideally my code should work and should be
fully robust, and that I need to ultimately address any reasons for
why exceptions would be thrown.

And I understand that if an exception gets caught and logged and the
code continues on its merry way, it might continue to confront
additional bugs related to the first issue.

But here's my situation. Tell me if it makes any sense. My code is in
beta and continues to undergo changes. This beta code gets used in
demonstrations to important visitors on big projector screens. It is
basically the visual component for a large system. It receives data
from this system on various sockets. In the case that I write code
that is imperfect and generates an exception, I would like for the
software to continue to run. Even if one thread dies I would like for
the rest of them to continue. I log these exceptions to a log file so
that I can go back to that file later and fix the software based on
the stack trace provided. My manager definitely wouldn't like it if
the software merely closed at the point of an exception.

I can see what you're saying about the advantages to catching specific
types of expected Exceptions, though, and providing code specific to
them.

Anyway, what do you think of my situation?

Thanks,
Julie
 
What should happen if you catch an exception and from that exception
handling code call a method which itself generates an exception that
gets caught? Is this sort of thing acceptable? Will the second
exception get caught? It seems like it should but I'm not absolutely
sure.
Click to expand...

Code that generates an exception from a catch block is common, I use
it often to translate & wrap a low-level exception (e.g. "cannot open
a file") to something higher level in my business logic (e.g. "there
was a problem processing a task where the file loading was an internal
detail").

However, it does not have the effect you anticipate. A catch block is
only triggered by exceptions generated from within its associated try
block, not by exceptions thrown from within itself. If you do not nest
another try ... catch within your catch block, the exception is handed
up to the most recent caller that has a try... catch handler for the
type thrown. If there is no such handler, the exception will go way up
to the entry point to the application, causing an abort of the
program.

[..]
I noticed that this logging code was not thread safe.
Click to expand...
[..]

This is a good guess. Try to use a critical section lock to prevent
simultaneous access to resources that cannot tolerate cuncurrency. See
http://msdn.microsoft.com/en-us/library/c5kehkcz(v=VS.100).aspx
for a description of the lock keyword.

best,

MiB.
 
What should happen if you catch an exception and from that exception
handling code call a method which itself generates an exception that
gets caught? Is this sort of thing acceptable? Will the second
exception get caught? It seems like it should but I'm not absolutely
sure.
Click to expand...

Code that generates an exception from a catch block is common, I use
it often to translate & wrap a low-level exception (e.g. "cannot open
a file") to something higher level in my business logic (e.g. "there
was a problem processing a task where the file loading was an internal
detail").

However, it does not have the effect you anticipate. A catch block is
only triggered by exceptions generated from within its associated try
block, not by exceptions thrown from within itself. If you do not nest
another try ... catch within your catch block, the exception is handed
up to the most recent caller that has a try... catch handler for the
type thrown. If there is no such handler, the exception will go way up
to the entry point to the application, causing an abort of the
program.

[..]> I noticed that this logging code was not thread safe.

[..]

This is a good guess. Try to use a critical section lock to prevent
simultaneous access to resources that cannot tolerate cuncurrency. Seehttp://msdn.microsoft.com/en-us/library/c5kehkcz%28v=VS.100%29.aspx
for a description of the lock keyword.

best,

   MiB.
Click to expand...

Oh, you're totally right! I didn't think it through enough on my own,
but I should have realized that within the catch block, I had no catch
occurring for the block.

Yes, I have since added critical sections. I don't know why I didn't
add them originally - dumb oversight.
 
It might. It depends on why the exception occurred. Some (many, in fact)
exceptions are "fine", as they are simply the result of some error
condition that is foreseeable and can be gracefully handled.

But yes, if you start writing code that just catches whatever exceptions
occur and let the program continue to run, all sorts of bad things might
happen. An exception that you did not anticipate could occur at any point
in the execution of the code, and continuing to run after such an exception
could lead to some invalid/corrupt program state.

In other words, not only could the original problem occur repeatedly, but
each time it occurs, it could introduce irregularities in your data
structures and other program state that lead to other new problems,
including new exceptions and corrupted or lost user data.


Then your manager needs to explain why he _does_ want the software to do,
and why he thinks that continuing to run is a good idea.  What other people
think about the topic might be informative, but even if your manager makes
unreasonable requirements, you may not be in a position to defy those
requirements.

That part of the question is much less a programming question and very much
more a personnel/business relationship question.

Re: demonstrations. Depending on your audience, but if you need to project
an image of infalliability, then you need to use a script for your
demonstration, making sure to exercise your program in only ways that have
already been thoroughly tested and found to be reliable.

If you let the program crash, then at least you can explain to an audience
that the crash is obviously due to a bug, and obviously the bug will be
fixed before the release of the software.  But if you attempt to allow the
program to continue running, you invite an even greater embarassment: a
program that hasn't crashed, but which is not responding correctly to user
input and is seen as unreliable.

A crash is obvious and while no one wants their software to crash, they
generally understand such failures can occur in pre-release software.
Software that is simply unreliable could easily be the consequence of a
programmer that is unreliable, and that's a much less desirable person to
be, I think.



I don't know enough about your situation to make any informed opinion or
pronouncements.  Maybe you need to catch exceptions, maybe you don't.  But
at the very least, I hope the opinions above give food for thought.

Pete
Click to expand...

Yes, thank you. I will give this whole thing more thought.
 
What should happen if you catch an exception and from that exception
handling code call a method which itself generates an exception that
gets caught? Is this sort of thing acceptable? Will the second
exception get caught? It seems like it should but I'm not absolutely
sure.
Click to expand...

As soon as you do anything real in a catch block then there is the
risk of that generating a new exception. That is unavoidable.

But unlike an exception in the normal execution flow where it is
common to recover, then trying to recover from an exception in
exception handling is questionable.
I have some code that crashed because of an exception not getting
caught, and I am trying to determine how this could have happened,
since I have "try/catch Exception" around all of my threads.

My "catch Exception" statements log the exception to a file; however,
I noticed that this logging code was not thread safe. So, it seems
quite possible that in handling an exception, a second exception would
be generated when the thread was attempting to simultaneously access
the log file at the same time as another thread.
Click to expand...

It could happen.

But I think the solution is simple: drop that home
made logging and use one of the widely used logging
frameworks - they are thread safe.

Arne
 
[..]> I noticed that this logging code was not thread safe.

[..]

This is a good guess. Try to use a critical section lock to prevent
simultaneous access to resources that cannot tolerate cuncurrency. Seehttp://msdn.microsoft.com/en-us/library/c5kehkcz%28v=VS.100%29.aspx
for a description of the lock keyword.
Click to expand...

Oh, you're totally right! I didn't think it through enough on my own,
but I should have realized that within the catch block, I had no catch
occurring for the block.

Yes, I have since added critical sections. I don't know why I didn't
add them originally - dumb oversight.
Click to expand...

For logging the synchronization should be done in the logging
framework not in the calling code.

Arne
 
Back
Top