classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: merge File.toURI() from Classpath


From: Bryce McKinlay
Subject: Re: Patch: merge File.toURI() from Classpath
Date: Wed, 07 Jul 2004 13:29:53 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040626)

Chris Pickett wrote:

5) Otherwise, if you need to throw an exception, and it is not strictly VM-related, and the user might have a hope of recovering, throw a subclass of RuntimeException, as per item (2).

6) Otherwise, throw something like UnrecoverableGNUClasspathError (needs deciding). Use this if the application must always die.


I'm not sure that its worth making up new exception classes. It seems to me that serious internal VM/low-level runtime errors that are unlikely to be recoverable should throw InternalError, where as other errors should throw RuntimeException (or some subclass thereof). I agree that the type of exception should be specialized as much as possible, however there are many circumstances that simply do not fit into any of the available subclasses. In these situations I think RuntimeException is the best choice, so a blanket ban on throwing RuntimeException doesn't seem reasonable.

7) Document using @throws and use the throws keyword as per Sun's API. If you document too much, this makes it difficult to adjust if Sun ever updates things, because users might rely on Classpath's old behaviour.


Again, these exceptions should be documented as part of our API documentation. They are exceptions that should _never_ happen. No call from the application should cause them to be thrown, thus they are not part of the API. If they are ever thrown, then there is a bug in classpath. Nevertheless, applications should have the ability to try and continue in the face of classpath bugs if they need fault tolerance.

Regards

Bryce.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]