tag:blogger.com,1999:blog-2479013339594661514.post4055750350649133147..comments2013-05-30T21:26:35.361+09:00Comments on shohe_i's Tech Blog: Defensive Programming - Being Defensive ModeratelyUnknownnoreply@blogger.comBlogger3125tag:blogger.com,1999:blog-2479013339594661514.post-72314481825086171862012-11-29T16:12:18.284+09:002012-11-29T16:12:18.284+09:00Great Post:)
your post helps me better understandi...Great Post:)<br />your post helps me better understanding because I was confused about contents of difensive programmer, such as exception and assertion. I am still trying to understand it. Any way, I understand why difensive programming is important for making for Safety Net and Program Efficiently. Thanks!Yoshihttps://www.blogger.com/profile/07903593233490097242noreply@blogger.comtag:blogger.com,1999:blog-2479013339594661514.post-45114839669418566462012-11-25T16:39:40.177+09:002012-11-25T16:39:40.177+09:00Sam,
Thank you very much for your comment! :)
&qu...Sam,<br /><br />Thank you very much for your comment! :)<br />"Having the run time code communicate effectively with the end user about problems it encounters seems the critical thing." - I strongly agree with your opinion .. will concentrate more while reading and definitely will try to write more quality, worth reading blog! :)Anonymoushttps://www.blogger.com/profile/13965319218763323773noreply@blogger.comtag:blogger.com,1999:blog-2479013339594661514.post-15615519951744605322012-11-25T16:14:09.153+09:002012-11-25T16:14:09.153+09:00Love the formatting :-) Of course remember that lo...Love the formatting :-) Of course remember that lots of assertions can adversely effect run-time performance, but then one certainly shouldn't prematurely optimize for performance. Still my personal preference is to wrap code in thorough tests as a way to defensively check that everything is as it seems. This has the advantage over assertions in the body of the code since the tests are a separate code base, don't impact run-time performance and provide a form of documentation about how the code should be used.<br /><br />Regarding the suggestions from code complete I would focus on error handling in general rather than specifically assertions myself. Having the run time code communicate effectively with the end user about problems it encounters seems the critical thing. If an assertion failing produces comprehensible output, e.g. the "denominator is unexpectedly zero" as in your above example, then it's just a type of general error handling. Part of the difference here is one of terminology from the C++ world to the Java world to the Ruby world. Whether you are throwing an exception, failing an assertion or throwing an error the key thing is the nature of the message, and how it will ultimately be presented to some consumer ...Sam Josephhttps://www.blogger.com/profile/10788506730233381803noreply@blogger.com