This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: primitive-throw wraps all exceptions (was: Kawa wraps Javaexceptions unexpectedly)


On Sun, 7 Oct 2001, Per Bothner wrote:

> Jocelyn Paine wrote:
> 
> >I see that the method kawa.standard.prim_throw.throw_it wraps its argument
> >in a runtimeException unless it already is one or an Error, so clearly
> >this wrapping is intended. 
> >
> Some wrapping is needed for checked exceptions since Scheme doesn't have any
> such concept, and it would not be reasonable to require that exceptions be
> statically declared in a dynamically typed language.  However, PrimProcedure
> should wrap the IOException in a WrappedException, not a RuntimeException.
> Then we have the options of later unwrapping.
>
> Whether handlers should unwrap is more difficult to say.

Any wrapping is confusing in that the documentation implies that if I
primitive-throw exception E, and E is an instance of a try-catch handler's
exception type, then that handler will be selected: "the first handler is
selected such that the thrown exception is an instance of the handler's
type". When reading this, I read "the thrown exception" as "that exception
that the programmer throws" rather than "that exception into which Kawa
chooses to convert what the programmer throws".

However, if it's necessary for the implementation, then so be it, but it
could be worth changing the description of primitive-throw and try-catch.

Wrapping in a WrappedException would be better, because wrapping in a
RuntimeException loses information. For example, one of the exceptions I
want to catch is a gnu.text.SyntexException thrown by 'read', in order to
display its SourceMessages as part of a syntax error message to help the
user. Currently, the only information about it that's left is the wrapping
RuntimeException's getMessage(), which doesn't include all the content of
the original exception, certainly not its error messages. Is there
actually any way to get hold of these under the current implementation?

As for implementation, I understand that in Java, the exceptions would
need to be declared. Is this also required by the JVM? In other words, if
method M throws a gnu.text.SyntaxException, say, but its translation into 
JVM doesn't declare this, is it then invalid JVM code?

Jocelyn Paine


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]