[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug classpath/22794] New: Threadgroup.uncaughtException shouldn't catch
From: |
pinskia at gcc dot gnu dot org |
Subject: |
[Bug classpath/22794] New: Threadgroup.uncaughtException shouldn't catch exceptions |
Date: |
1 Oct 2005 17:27:19 -0000 |
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.
------- Additional Comments From from-classpath at savannah dot gnu dot org
2004-11-03 00:34 -------
Here is how I have rewritten uncaughtException to not perform any direct
allocation and to be more resilient to OutOfMemory conditions:
public void uncaughtException(Thread thread, Throwable t) {
if (parent != null)
parent.uncaughtException(thread, t);
else if (!(t instanceof ThreadDeath)) {
had_uncaught_exception = true; // this makes little sense!
// avoid all allocation and catch any cascading OOME's
String name = INDETERMINATE;
try {
name = thread.getName();
}
catch (OutOfMemoryError oome) {
}
System.err.print(MSG1);
System.err.print(name);
System.err.print(MSG2);
try {
// We could do this in a temporary scope, but there's no
// guarantee about the size of scope we would need, nor can we
// be sure some custom exception object doesn't have a bad
// implementation that will throw an exception that would then
// try to exit the scope. Simpler just to let this fail.
t.printStackTrace(System.err);
}
catch (OutOfMemoryError oome) {
String throwable = null;
try {
throwable = t.toString();
}
catch (OutOfMemoryError oome2) {
if (t instanceof OutOfMemoryError)
throwable = OOME;
else
throwable = INDETERMINATE;
}
System.err.print(throwable);
System.err.println(NOSTACK);
}
}
}
static final String MSG1 = "Exception in thread \"";
static final String MSG2 = "\": ";
static final String INDETERMINATE = "<indeterminate>";
static final String OOME = "OutOfMemoryError";
static final String NOSTACK = "\t<No stack trace available>";
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-10-01
17:27 -------
Confirmed.
--
Summary: Threadgroup.uncaughtException shouldn't catch exceptions
Product: classpath
Version: unspecified
Status: NEW
Severity: normal
Priority: P3
Component: classpath
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: from-classpath at savannah dot gnu dot org
CC: bug-classpath at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22794
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug classpath/22794] New: Threadgroup.uncaughtException shouldn't catch exceptions,
pinskia at gcc dot gnu dot org <=