harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: [classlib][summary] Exception throwing compatibility
Date Wed, 09 Aug 2006 09:16:40 GMT
I think that as long as the spec says throws java.x.Y, and we throw a
java.x.Y (or an o.a.h subclass of java.x.Y) then that meets the spec.

I think the wording could be clearer though; for example, the 'public
superclass' is almost certainly meant to be 'an exception in the
standard Java class libraries'. For a start,
sun.io.MalformedInputException might actually be a subclass of
sun.io.GeneralInputException, which has the ACC_PUBLIC bit set (even
though it's not a defined class in the Java spec).

Perhaps "If the exception thrown is a direct instance of an exception
from the Java libraries, we will throw the same exception; if it is an
instance of an exception not in the Java libraries then we will throw
an equivalent o.a.h exception or a parent exception in the Java
libraries". It's possible that there's an exception class which is
abstract that we must create a subclass for, though off the top of my
head I can't think of an abstract exception class in the Java
libraries ...


On 09/08/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> "But there are some cases that RI throws an implementation specific
> exception, we shall throw its public superclass. e.g., If RI throws
> sun.io.MalformedInputException, we shall throw
> java.io.CharConversionException. "
> I think it's OK to throw Harmony-implement subclass of the public superclass
> for some cases? Do you think so?

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message