Re: Declaring RuntimeExceptions?
> "Sascha" == Sascha Brawer <[EMAIL PROTECTED]> writes: Sascha> So, should a java compiler accept the following? Sascha> [ ... ] Sascha> javac 1.4.1 compiles this code, but gcj 3.2 complains about the throws Sascha> clause (of *Foo*.meth, which is a bit misleading). BTW, this bug is gone in current cvs. It might also be fixed in 3.3, but I didn't try it to see. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Declaring RuntimeExceptions?
> So, should a java compiler accept the following?
>
> // java.awt.HeadlessException
> // extends java.lang.UnsupportedOperationException
> // extends java.lang.RuntimeException
>
> class Foo
> {
> void meth() throws java.awt.HeadlessException { }
> }
>
> class Bar
> extends Foo
> {
> void meth() { }
> }
The code is valid in that its okay for a subclass to declare fewer
exceptions on an overriding method - checked or unchecked. Hence
Bar.meth is correctly defined and must be accepted by any compiler.
However, a compiler could complain that Foo.meth can never throw the
declared HeadlessException (as it should for a checked exception) and
refuse to compile it. I think it would be a bit over-zealous, though
not "illegal", to do so.
David Holmes
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
Sascha,
> So, should a java compiler accept the following?
>
> // java.awt.HeadlessException
> // extends java.lang.UnsupportedOperationException
> // extends java.lang.RuntimeException
>
> class Foo
> {
> void meth() throws java.awt.HeadlessException { }
> }
>
> class Bar
> extends Foo
> {
> void meth() { }
> }
Yes it should.
Refer to the JLS Section 8.4.4. The last two paragraphs read as follows:
A method that overrides or hides another method (§8.4.6), including
methods that implement abstract methods defined in interfaces, may
not be declared to throw more checked exceptions than the overridden
or hidden method.
More precisely, suppose that B is a class or interface, and A is a
superclass or superinterface of B, and a method declaration n in B
overrides or hides a method declaration m in A. If n has a throws
clause that mentions any checked exception types, then m must have
a throws clause, and for every checked exception type listed in the
throws clause of n, that same exception class or one of its superclasses
must occur in the throws clause of m; otherwise, a compile-time error
occurs.
Note that these rules are for >>checked<< exceptions only; i.e. exception
classes that are NOT subtypes of Error or RuntimeException.
> javac 1.4.1 compiles this code, but gcj 3.2 complains about the throws
> clause (of *Foo*.meth, which is a bit misleading).
gcj 3.2 is clearly wrong, IMO.
-- Steve
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
So, should a java compiler accept the following?
// java.awt.HeadlessException
// extends java.lang.UnsupportedOperationException
// extends java.lang.RuntimeException
class Foo
{
void meth() throws java.awt.HeadlessException { }
}
class Bar
extends Foo
{
void meth() { }
}
javac 1.4.1 compiles this code, but gcj 3.2 complains about the throws
clause (of *Foo*.meth, which is a bit misleading).
Note that Foo may be a JDK class, and Bar some user class. If the above
code does not conform to the language specification, i.e. gcj is right,
our Foos must declare exactly the same exceptions as the JDK, or existing
user code may not compile with Classpath.
-- Sascha
Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
I agree with Tom that we should not declare unneeded exceptions, even when Sun does. Not all compilers emit RuntimeExceptions into the .class file to begin with. Reflection data is not guaranteed to be the same between two compilers, even if you DO declare the RuntimeExceptions, because compilers have the right to optimize for size and omit wasting the space on the useless declaration information. Therefore, code relying on the declared RuntimeExceptions returned by reflection is just asking for problems. David Holmes wrote: Standard practice - as epoused by various books and articles from various source related to Sun - is to not declare RuntimeExceptions on a throws clause. Such exceptions should be documented in the javadoc only. However, the reflection issue is not something I was aware of. If indeed reflection returns all declared throwables whether runtime exceptions or not, then there will be a behavioural difference - though not one that anybody should ever be relying upon. This situation is also clouded by the default rules for inheriting @throws documentation comments, which will only inherit comments for exceptions that are listed in the throws clause. The way around this is to not declare the exception but instead to the use @inheritDoc to force the inheritance of the doc comment eg: @throws someRuntimeException [EMAIL PROTECTED] but some people may start declaring the runtime exceptions just to inherit the doc comments. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Declaring RuntimeExceptions?
Standard practice - as epoused by various books and articles from various source related to Sun - is to not declare RuntimeExceptions on a throws clause. Such exceptions should be documented in the javadoc only. However, the reflection issue is not something I was aware of. If indeed reflection returns all declared throwables whether runtime exceptions or not, then there will be a behavioural difference - though not one that anybody should ever be relying upon. This situation is also clouded by the default rules for inheriting @throws documentation comments, which will only inherit comments for exceptions that are listed in the throws clause. The way around this is to not declare the exception but instead to the use @inheritDoc to force the inheritance of the doc comment eg: @throws someRuntimeException [EMAIL PROTECTED] but some people may start declaring the runtime exceptions just to inherit the doc comments. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
> "Ingo" == Ingo Prötel <[EMAIL PROTECTED]> writes: Ingo> If you do a getExceptionTypes() on java.lang.reflect.Method you will get Ingo> all declared Throwables. This includes RuntimeExceptions and Errors that Ingo> are declared to be thrown by a method (also for constructors). Let me offer a contrarian view. I think declaring these exceptions is a bit ugly. It is unnecessary. I've always viewed the cases where Sun has done this as simple mistakes on their part. Second, I doubt there is any program out there that actually relies on this. So while this is a theoretical difference, in practice I think it will affect nothing. Plus, we have a good argument that code relying on this is incorrect anyway. Sun could easily remove these declarations in a future version; after all, it affects neither source nor binary compatibility. We are already not reflection-compatible at other places. For instance, we don't always implement the same overloads that Sun does. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
Hi, I do agree with Ingo, the methods should report any exception that may be throw explicitly. Of course, methods won't declare the well know NullPointerException, or ArrayIndexOutOfBounds... etc. but exceptions that are trhown, such as the HeadlessException, should be reported, not only 'cos the sun does so, but I think it is a good practise, I mean, anyone who looks at the method signature will notice that it can trhow that kind of exception, without looking at the code. And there's also the reflection... so I guess it's better to declare them, as this will still keep backward and "sideward"(does this word exists?) compatibility... -- otavio --- Ingo_Prötel <[EMAIL PROTECTED]> wrote: > Hi Sascha, > > I think Classpath should also declare RuntimeExceptions if JDK does so. > > If you do a getExceptionTypes() on java.lang.reflect.Method you will get > all declared Throwables. This includes RuntimeExceptions and Errors that > are declared to be thrown by a method (also for constructors). > > So, to keep the runtime-behavoir of such objects consistent we need to > declare such Exceptions even if the compiler does require it. > > --ingo > > Sascha Brawer wrote: > > Hi all, > > > > if the signature of a JDK method declares to throw some RuntimeException, > > should the Classpath do so, too? > > > > For example, java.awt.Toolkit.createButton declares to throw > > java.awt.HeadlessException in the JDK, but not in Classpath. > > HeadlessException extends java.lang.RuntimeException. > > > > -- Sascha Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
Hi Sascha, I think Classpath should also declare RuntimeExceptions if JDK does so. If you do a getExceptionTypes() on java.lang.reflect.Method you will get all declared Throwables. This includes RuntimeExceptions and Errors that are declared to be thrown by a method (also for constructors). So, to keep the runtime-behavoir of such objects consistent we need to declare such Exceptions even if the compiler does require it. --ingo Sascha Brawer wrote: Hi all, if the signature of a JDK method declares to throw some RuntimeException, should the Classpath do so, too? For example, java.awt.Toolkit.createButton declares to throw java.awt.HeadlessException in the JDK, but not in Classpath. HeadlessException extends java.lang.RuntimeException. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
Sascha Brawer <[EMAIL PROTECTED]> writes: > Hi all, > > if the signature of a JDK method declares to throw some RuntimeException, > should the Classpath do so, too? > > For example, java.awt.Toolkit.createButton declares to throw > java.awt.HeadlessException in the JDK, but not in Classpath. > HeadlessException extends java.lang.RuntimeException. It's not necessary to use a 'throws' clause with RuntimeException or subclasses. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Declaring RuntimeExceptions?
Hi all, if the signature of a JDK method declares to throw some RuntimeException, should the Classpath do so, too? For example, java.awt.Toolkit.createButton declares to throw java.awt.HeadlessException in the JDK, but not in Classpath. HeadlessException extends java.lang.RuntimeException. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
