Michael Koch wrote: > Hello, > On Mon, Nov 05, 2007 at 10:49:29AM +0900, Sanghyeon Seo wrote: >> In the original modifed file, ParseException extends CSSException >> which extends RuntimeException, so it is an unchecked exception. But >> unmodifed ParseException extends Exception by default, which makes it >> a checked exception, but methods throwing ParseException doesn't >> declare to throw it, resulting in compile error. > > Thats close to the worst things library developers can do... > > This makes me really scared about this. Depending on such a library in a > distro is like depending on dynamite to not explode.
I would say it's not _entirely_ the library developers' fault. JavaCC has always had a rather inconsistent use of Exceptions - ParseException (thrown for syntactic errors) extends Exception, but TokenMgrError (thrown for lexical errors) extends Error. It's not surprising users get in a pickle. Having said that, I would certainly think it would be better to trap the (unchecked) TokenMgrError and convert it to a (checked) ParseException. (And sometimes it is quite appropriate for a ParseException to be treated as a RuntimeError - e.g. if you are using the parser on known-good input. I've not checked if that's the case for flute). The next release of JavaCC should make things a little more logical: https://javacc.dev.java.net/issues/show_bug.cgi?id=12 Thanks, Paul. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
