Not quite. Placing a throws clause of a *RuntimeException* will not cause a compile error, but it is not necessary - it misleads the caller into thinking they should program for it. Its best to just javadoc the RuntimeExceptions with @throws, and not to declare them in the signature. Bottom line: Best practice is to put a throws clause in the signature when the checked exception is *recoverable* by the client.
-----Original Message----- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 9:26 AM To: 'Struts Users Mailing List' Subject: RE: Basic (esoteric) Question So, if I understand you correctly, placing a <throws> clause in the signature for a runtime error does not burden the client, whereas the same for a checked exception will burden the client (force the client to traverse the exception tree)? Does this operate similarly within a try-catch block? -----Original Message----- From: Jeff Oberlander [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 12:20 PM Indirectly yes. A declared exception (Checked) forces the caller to implement code to check for that exception. So there is overhead to the client and it can make the API more complex for the client. Generally, throw a checked exception for conditions the caller can expect to recover. Unchecked exceptions (subclasses of RuntimeException) typically mean that the error is not recoverable and programming errors - thus the client will fail, but you've eliminated the client code checking for the exceptions. -----Original Message----- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 8:46 AM To: Servlets (E-mail); J2ee (E-mail); Struts (E-mail) Subject: Basic (esoteric) Question Does anybody know of any design considerations that would affect the performance of a method that declares a <throws> in its signature vs. an exception that is either caught or thrown new in the <try-catch> block? Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
