[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[commit-cp] [bugs #10869] Threadgroup.uncaughtException shouldn't catch
From: |
David Holmes |
Subject: |
[commit-cp] [bugs #10869] Threadgroup.uncaughtException shouldn't catch exceptions |
Date: |
Tue, 02 Nov 2004 02:17:59 -0500 |
User-agent: |
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; Q312461; .NET CLR 1.0.3705; .NET CLR 1.1.4322) |
This mail is an automated notification from the bugs tracker
of the project: classpath.
/**************************************************************************/
[bugs #10869] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10869>
Project: classpath
Submitted by: David Holmes
On: Tue 11/02/2004 at 07:04
Category: classpath
Severity: 5 - Average
Resolution: None
Privacy: Public
Assigned to: None
Status: Open
Platform Version: None
Summary: Threadgroup.uncaughtException shouldn't catch exceptions
Original Submission: Threadgroup.uncaughtException essentially does this:
try
{
if (thread != null)
System.err.print("Exception in thread "" + thread.name + "" ");
t.printStackTrace(System.err);
}
catch (Throwable x)
{
// This means that something is badly screwed up with the runtime,
// or perhaps someone overloaded the Throwable.printStackTrace to
// die. In any case, try to deal with it gracefully.
try
{
System.err.println(t);
System.err.println("*** Got " + x
+ " while trying to print stack trace.");
}
catch (Throwable x2)
{
// Here, someone may have overloaded t.toString() or
// x.toString() to die. Give up all hope; we can't even chain
// the exception, because the chain would likewise die.
System.err.println("*** Catastrophic failure while handling "
+ "uncaught exception.");
throw new InternalError();
}
}
}
These secondary catches should not be present. Any exceptions that happen to
occur during the attempt to handle the uncaught exception should simply be
allowed to propogate. The VM has responsibility for invoking uncaughtException
and thus handling, or ignoring any exceptions generated from it.
Consider for example, if the uncaught exception is OutOfMemoryError - all these
attempts to handle it will simply trigger more and more OutOfMemoryError
conditions. Such conditions should not pollute System.err with these extra
"debug" like messages, nor should the exception be converted to an
internalError. In the latter case if throwing internalError "succeeds" then all
you have done is mask what really went wrong.
Keep it simple: uncaught exception should just attempt to print the stack trace
and nothing else.
For the record this is biting me in a Realtime JVM using RTSJ ScopedMemory,
where OutOfMemoryError (OOME)leading to abrupt thread termination is quite easy
to trigger. I handle the OOME in the caller of UncaughtException but a better
solution is to re-write UncaughtException to be more OOME aware.
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=10869>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [commit-cp] [bugs #10869] Threadgroup.uncaughtException shouldn't catch exceptions,
David Holmes <=