tag:blogger.com,1999:blog-3237724005744642470.post7978752279142666300..comments2020-11-17T09:20:38.485+00:00Roger Hugheshttp://www.blogger.com/profile/07042290171112551665[email protected]Blogger4125tag:blogger.com,1999:blog-3237724005744642470.post-29305393291530462292013-08-01T13:23:42.427+01:002013-08-01T13:23:42.427+01:00@Frisian would you agree that there are good cases for defensive programming and bad ones as illustrated in the article?EZhttps://www.blogger.com/profile/00359372520780207377[email protected]tag:blogger.com,1999:blog-3237724005744642470.post-35786510133896853242013-04-12T13:09:05.938+01:002013-04-12T13:09:05.938+01:00Au contraire, I think there is a difference between defensive programming and fail-fast programming:<br />Fail-fast programming is about letting something wrong fail as soon as possible. Defensive programming on the other hand about not letting something bad happen and telling about the problem in a concise way.<br />java.util.Iterator is a good example for fail-fast programming, by virtue of throwing an exception as soon as a concurrent modification is detected. Yet, the contract doesn&#39;t go further than that, i.e. the exception doesn&#39;t tell you the actual cause.<br />Defensive programming, like shown in your first example, tells the reason of failure as exact as possible. So, it would be perfectly fine to catch an ArithmeticException after the calculation occurred and then tell the caller about why it happened (i.e. height is 0).<br />Putting validation at the begin of a method is a mere convention to to separate it from the actual business logic.<br />Especially with transactions fail-fast code looks quite different from defensive code. Validation code can be put everywhere, because the transaction manager does the clean up. Deferred database constraints are a good example for defensive programming as the violation is signalled only after the commit.Frisian[email protected]tag:blogger.com,1999:blog-3237724005744642470.post-36341091618072983402013-04-08T20:56:11.660+01:002013-04-08T20:56:11.660+01:00Strictly speaking I guess that you&#39;re right, it does break the SRP. If this were a &#39;proper&#39; web app and I was validating user inputs, then I&#39;d use a &#39;proper&#39; validation technique. In writing this blog, I was thinking more about detecting programming errors in an API, which means that I&#39;m really using the Validate class rather like Java&#39;s assert with the idea being to let it fail and then to fix it.Roger Hugheshttps://www.blogger.com/profile/07042290171112551665[email protected]tag:blogger.com,1999:blog-3237724005744642470.post-76322323167383866582013-04-08T11:13:15.143+01:002013-04-08T11:13:15.143+01:00I agree with fail-fast, but the validation code for your BMI calculator seems to break the SRP (it validates *and* calculates BMI).<br /><br />How would you get around this?Ricardohttps://www.blogger.com/profile/14634420499207397879[email protected]