tag:blogger.com,1999:blog-993833610256227478.post8209877821949300179..comments2008-05-20T09:56:41.272+01:00Fredrik Rubenssonhttp://www.blogger.com/profile/01768658671349714371noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-993833610256227478.post-78773247018493638222008-05-20T09:56:00.000+01:002008-05-20T09:56:00.000+01:00Agreed - there always has been this huge discussion around checked vs unchecked exceptions and a lot of bogus code has been written. I like an article on ONJava a lot <A HREF="http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html" REL="nofollow">Best Practices for Exception Handling</A>. To quote from this article:"Ask yourself, what action can the client code take when the exception occurs?<BR/>If the client can take some alternate action to recover from the exception, make it a checked exception. If the client cannot do anything useful, then make the exception unchecked. By useful, I mean taking steps to recover from the exception and not just logging the exception." <BR/>I think that's a very healthy approach.<BR/><BR/>Regarding the code example - there is a reason why one would like to fail early. Imagine only one of the passed in parameters is null, component. Now let your method modify initially the other object. What happens now if the method tries to call a method on null object. You will get a NullPointerException, but you also have already modified another object. This could in some scenarios have side unwanted side effects. I guess that would justify the guarding null check.<BR/><BR/>Admittedly the code looks silly. I would like to see built in support for <B>Design By Contract</B> within Java - a la <A HREF="http://www.contract4j.org" REL="nofollow">Contract4J</A>.Hardy Ferentschikhttp://www.blogger.com/profile/09313517265555235117noreply@blogger.com