Adding a throws UncheckedException to an API does not require code calling
that API to either catch that exception or declare it to be rethrown. The
compiler will not help you here by enforcing handling unchecked
exceptions.
public class Unchecked {
public void foo() throws RuntimeException {
throw new RuntimeException();
}
public void bar() {
foo();
}
}
compiles with no warning that bar() must handle the unchecked exception
when calling foo(). So there is no more "safety" to be had by declaring
unchecked exceptions in API.
As I side note, I think checked exceptions are hideous but they are part
of Java so we deal with them.
PS. I would also suggest you use the Shift key when writing as your
writing is very difficult to read without proper capitalization. It begins
to look like one long run-on sentence. :-)
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: <[email protected]>
To: <[email protected]>
Date: 2010/09/13 14:46
Subject: Re: [osgi-dev] org.osgi.framework.BundleContext has many
javadoc @throws tags but missing most "throws" clauses
Sent by: [email protected]
thanks for the explanation, BJ.
the genesis of the patch was that, during eclipse PDE, i encountered at
least one instance where the compiler could have warned about a potential
throw that was not caught until runtime because the original developer did
not heed the javadoc tags, and the code could have caught the exception
thrown from ungetService() and continued cleanup without any real adverse
side-effects.
and there is this:
http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html
"… the compiler does not require that you catch or specify runtime
exceptions (although you can).
Generally speaking, do not throw a RuntimeException or create a subclass
of RuntimeException simply because you don't want to be bothered with
specifying the exceptions your methods can throw."
i understand the general convention. and i understand in the case of the
calling PDE code, the problem lies perhaps in the logic of the shutdown
being possibly faulty. i'm just also in favor of catching stuff like this
at compile time, and going against convention in this case would have
enforced this to be dealt with up front.
i'll leave it at that. if it changes in a future release, great. if not,
i appreciate the consideration and your time in thinking about it in any
case. thanks.
++ kirk
On 2010-Sep-13, at 11:00 AM, ext BJ Hargrave wrote:
As a API design convention, The OSGi API does not declare unchecked
exceptions in the API. They are just documented in the @throws javadoc
tag. As required by the Java language, all checked exception are declared
in the API.
See item 62 in Effective Java, 2nd Edition.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: <[email protected]>
To: <[email protected]>
Date: 2010/09/13 13:32
Subject: [osgi-dev] org.osgi.framework.BundleContext has many
javadoc @throws tags but missing most "throws" clauses
Sent by: [email protected]
org.osgi.framework.BundleContext has javadoc containing many @throws tags.
however most of the interfaces are missing the corresponding throw
clauses.
the fact that some of the function interfaces have some (but in some cases
not all) such thrown exceptions identified indicates that there probably
is not a policy governing this.
having all throws clauses included could help identify at compile time
instances in callers that either need to handle or need to report they
will throw these exceptions.
find attached a simple patch that creates "throws" clauses from all
"@throws" tags found in BundleContext.
++ kirk beitz : nokia : austin + san diego : [email protected] ++
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
