I understand the difference between different types of throwables, the point
I was trying to make is that where a RuntimeException may be thrown by a
method, it is normal for the javadoc to document the conditions under which
it is thrown. This is the point I was trying to make wth the Comparable
example.
Now whilst I agree that the code will compile, I think you are breaking the
contract layed out by Object.equals if you implement it such that it throws
a ClassCastException.
cheers
dim
----- Original Message -----
From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]>
To: "'Dmitri Colebatch'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, June 26, 2002 12:43 PM
Subject: RE: hashcode and equals method
> Whenever a method is overriden in Java, the Exceptions it may throw are
> either the ones defined in the overriden method or a subset of them:
>
> public class NeoObject extends Object {
> public boolean equals(Object other)
> throws java.util.zip.DataFormatException {
>
> return (...);
> }
> }
>
> Won't compile since DataFormatException isn't in the throws clause for
> the equals method in java.lang.Object.
>
> There are(chap. 11 Java Language Specification) three kinds of
> exceptions, all which extend java.lang.Throwable.
>
> Errors:
> 11.2.1 Why Errors are Not Checked
> Those unchecked exception classes which are the error classes (Error and
> its
> subclasses) are exempted from compile-time checking because they can
> occur at
> many points in the program and recovery from them is difficult or
> impossible. A
> Java program declaring such exceptions would be cluttered, pointlessly.
>
> Runtime Exceptions a.k.a. Unchecked Exceptions
>
> 11.2.2 Why Runtime Exceptions are Not Checked
> The runtime exception classes (RuntimeException and its subclasses) are
> exempted from compile-time checking because, in the judgment of the
> designers
> of Java, having to declare such exceptions would not aid significantly
> in establishing
> the correctness of Java programs. Many of the operations and constructs
> of the
> Java language can result in runtime exceptions. The information
> available to a
> Java compiler, and the level of analysis the compiler performs, are
> usually not suf-
> ficient to establish that such runtime exceptions cannot occur, even
> though this
> may be obvious to the Java programmer. Requiring such exception classes
> to be
> declared would simply be an irritation to Java programmers.
> For example, certain code might implement a circular data structure
> that, by
> construction, can never involve null references; the programmer can then
> be
> certain that a NullPointerException cannot occur, but it would be
> difficult for a
> compiler to prove it. The theorem-proving technology that is needed to
> establish
> such global properties of data structures is beyond the scope of this
> Java Language
> Specification.
>
> And then the regular exceptions. One could maintain that all Runtime
> Exceptions are implicitly included in the throws clause of any method.
>
> Because of the particular semantics involving RuntimeExceptions,
> throwing them or catching them is arbitrary and up to the programmer to
> embrace or reject. I won't presume of being the ultimate reference of
> Java either, but I think that the bottom line is, throwing
> ClassCastException is up to the programmer and the business domain.
> Hence, it may make sense not to throw ClassCastException in some cases,
> presumably, less purpose-specific classes such as complex Value classes,
> like Date or BigInteger.
>
> My 2c,
>
>
> Juan Pablo Lorandi
> Chief Software Architect
> Code Foundry Ltd.
> [EMAIL PROTECTED]
>
> Barberstown, Straffan, Co. Kildare, Ireland.
> Tel: +353-1-6012050 Fax: +353-1-6012051
> Mobile: +353-86-2157900
> www.codefoundry.com
>
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Dmitri Colebatch
> > Sent: Wednesday, June 26, 2002 3:12 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: hashcode and equals method
> >
> >
> > As I read it, the arguements have been about "handling the
> > exception" in the component - in this case in the equals method.
> >
> > Cedric, quite rightly, has pointed out that the equals method
> > should return true or false - no indication of an exception
> > being thrown is mentioned in the javadoc. Compare this to
> > the javadoc for Comparator, which _explicitly_ states, that a
> > ClassCastException is thrown if the objects are not the
> > correct type (and in Comparable).
> >
> > There are two issues:
> > 1. where to handle exceptions
> > 2. can equals throw a ClassCastException.
> >
> > Cedric is saying "no" to 2. I think you have been arguing point 1.
> >
> > my 2c
> >
> > cheers
> > dim
> >
> > ----- Original Message -----
> > From: "Enda" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, June 26, 2002 12:22 AM
> > Subject: Re: hashcode and equals method
> >
> >
> > > entirely correct, but what has that got to do with the
> > correctness /
> > > incorrectness of handing exceptions in a component instead of a
> > > container? I think you missed my point.
> > >
> > > -Enda.
> > >
> > > ----- Original Message -----
> > > From: "Cedric Beust" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Tuesday, June 25, 2002 3:12 PM
> > > Subject: Re: hashcode and equals method
> > >
> > >
> > > > > From: A mailing list for Enterprise JavaBeans development
> > > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Enda
> > > >
> > > > > Exceptions are not thrown to be caught and hidden away from
> > > > > console screens, they are there to tell you that
> > somthing has gone
> > > > > wrong.
> > > >
> > > > This is true in general but incorrect for equals().
> > > >
> > > > The contract of equals() is crystal clear: if the objects are
> > > > identical, return true, otherwise return false.
> > > >
> > > > If I compare an AddressPK with an EmployeePK, the result
> > should be
> > > > false. Anything else, even an exception, is a breach in the
> > > contract of
> > > > equals().
> > > >
> > > > --
> > > > Cedric
> > > >
> > > >
> > >
> > ======================================================================
> > > =====
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> > > the body
> > > > of the message "signoff EJB-INTEREST". For general help,
> > send email
> > > to
> > > > [EMAIL PROTECTED] and include in the body of the
> > message "help".
> > > >
> > > >
> > > >
> > >
> > >
> > ==============================================================
> > =============
> > > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the
> > body
> > > of the message "signoff EJB-INTEREST". For general help,
> > send email
> > > to [EMAIL PROTECTED] and include in the body of the message
> > > "help".
> > >
> > >
> >
> > ==============================================================
> > =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the body of the message "signoff EJB-INTEREST".
> > For general help, send email to [EMAIL PROTECTED] and
> > include in the body of the message "help".
> >
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
