This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi, On Wed, 2004-07-07 at 05:21, Stephen Crawley wrote: > For the record, grep tells me that Sun's JDK 1.4.2 class libraries > throws InternalError in 145 places. Notwithstanding the wording of the > InternalError javadoc, Sun uses it extensively for library errors. In a > couple of cases, the comments that indicated that the developer thought > that InternalError was the wrong exception ... but used it anyway. > > On the other hand, grep tells me that JDK 1.4.2 throws RuntimeException > in 157 places. Quick note. As pointed out in the GNU Classpath Hacker Guide http://www.gnu.org/software/classpath/docs/hacking.html#SEC2 Never under any circumstances refer to proprietary code while working on GNU Classpath. GNU Classpath can be developed while just relying on free software tools. Please make this as easy as possible for everybody and just use only free software whenever you can. Yes, I know that running grep over a bunch of source files isn't the same as studying some proprietary implementation while working on a free implementation like GNU Classpath. But we like to make it as clear and easy as possible to avoid any confusion about whether or not people hacking on GNU Classpath ever refer to proprietary implementations while working on compatible free implementations. They don't. Keeping it that simple means we don't have to open up a giant can of legal worms. It can easily be kept closed. Thanks, Mark BTW. FWIW. I think Chris has it right. The book by Joshua Bloch makes a very good case. We should just define a ClasspathAssertionFailure that extends RuntimeException and takes a cause (and/or string) as argument. Then at every place we get an unexpected exception that should not happen or some other pre/post condition failure inside the core libraries that was never supposed to happen we throw this. It doesn't even matter that much what another implementation does. We should do it better and more consistent.
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |