Patrick Tullmann <[EMAIL PROTECTED]> writes:
> Tim Stack wrote:
> > Preloading in this case means checking if a class references
> > StackOverflowError or any of its ancestors and then having the class
> > loader load them in, or we just treat them as "special classes" that
> > magically resolve to system classes regardless of the class loader.
>
> I'm not sure if that's sufficient. For example this code:
>
>
> ...
> try {
> wasteLotsofStackSpace();
> } catch (SomeAppSpecificException i) {
> ...
> }
> ...
>
> may still invoke the ClassLoader and call out into Java code in the
> exception dispatching path.
>
> The problem is really that the exception dispatch path may wander out
> into arbitrary Java code (via loadClass()).
>
> It seems to me that the solution is to make sure that all Class names
> referenced in a catch clause are resolved before any code in the
> corresponding try block is executed. Can we just get away with making
> sure all class names referenced in a catch block are resolved when the
> method is compiled?
That seems fair, since the JVM is supposed to check that they are <:
Throwable anyway. As for classes loaded by the catch body, is this
really a problem? Once a StackOverflow has been dispatched, we
should be able to throw a new one and make progress.
Jason
