On 4/25/06, Dmitry M. Kononov <[EMAIL PROTECTED]> wrote:
> On 4/25/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > Jimmy, Jing Lv wrote:
> > > I agree.
> > > But there are at least two exceptional situation:
> > > 1) several exceptions throws from one method, which extend one parent
> > > class, e.g. ConnectionException and UnknownHostException, javadoc writes
> > > "throws IOException" rather than "throws
> > > ConnectionException,UnknownHostException". And in implementation, we
> > > shall throw them out directly instead of
> > > try{...
> > > }catch(UnknownHostException e){
> > >     throw new IOException();
> > > }
> > > catch(ConnectionException e){
> > >     throw new IOException();
> > > }
> > > right? :)
> >
> > +1, and other instances where super-types or super-interfaces declare
> > compatible throws clauses that are implemented in subclasses that throw
> > more specific subtypes.  I do not agree that we should be bound to throw
> > and exception of the identical type as the declaration.
>
> If we want to follow the spec and if we want to restrain ourself from
> "improving" the spec, I think we really need to throw IOException. If
> this exception can be caused by different ways we apparently have to
> throw IOException with an appropriate cause.

>From the general perspective, in the example above re-throwing
IOException looks quite ugly. Besides, it hides some important
information (since Java uses exception sub-classing to represent the
particular type of problem). However we are not free with design, I
think. Could someone please remind me an idea: for the example above
do we mean that the spec states IOException and RI throws exactly
IOException (I traversed the thread, but still not sure what was
meant)?
The idea behind the question is: why not just copy RI in this case
(conforming Tim's guidelines)?

--
Anton Avtamonov,
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to