tag:blogger.com,1999:blog-7577421612120825312.post5357995128623106624..comments2023-10-03T10:41:13.944+01:00Comments on Functional Fun: DebuggerNonUserCode: Suppressing ignorable exceptions in the debuggerAnonymoushttp://www.blogger.com/profile/01345100698738870730noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-7577421612120825312.post-35867932876022461472009-07-14T19:50:12.233+01:002009-07-14T19:50:12.233+01:00This is going to be so useful to suppress those Bi...This is going to be so useful to suppress those BindingFailure exceptions you have no control over when using XmlSerializer! Thanks!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7577421612120825312.post-53747710685374635192008-05-23T16:37:00.000+01:002008-05-23T16:37:00.000+01:00:-) I can see how the guideline can be interpreted...:-) <BR/>I can see how the guideline can be interpreted the way you did (and is probably written with a bit too strong language). But the point of the guideline was to strongly suggest that API designers provide APIs to allow users to check preconditions, if possible. If it's not possible, TryParse can be used to alleviate pref problems, if perf is deemed to be an issue. In case of Parse, checking preconditions is not practical, so TryParse might, but not automatically, apply.<BR/>Too strict interpretation of the guideline could lead to Try* methods sprinkled all over APIs. It seems like it would be bad, i.e. lots of unnecessary noise. Also, we would pretty much be back to the world of error codes (worse error codes with 2 values only). This would erase benefits of exceptions that are described at the beginning of the FDG chapter.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7577421612120825312.post-11372320927027269432008-05-21T09:21:00.000+01:002008-05-21T09:21:00.000+01:00Krzysztof, Who am I to argue with the author of t...Krzysztof,<BR/> Who am I to argue with the author of the guidelines? (And I'll admit that my introduction to this article was exaggerated, for effect.)<BR/><BR/>However, on page 186 of your book I find it written "DO NOT use exceptions for the normal flow of control if possible". The passage goes on to say that "framework designers should design API's so users can write code that does not throw exceptions." <BR/><BR/>In order to avoid exceptions when parsing user input involving Enum values, you have to take a much longer route round, as Michael Goldobin did at the link above. This seems to me to go against the guidelines.<BR/><BR/>Will we see TryParse in .Net 4.0?<BR/><BR/>Anyway, thanks for leaving your thoughts!Anonymoushttps://www.blogger.com/profile/01345100698738870730noreply@blogger.comtag:blogger.com,1999:blog-7577421612120825312.post-52383695181441396942008-05-21T04:19:00.000+01:002008-05-21T04:19:00.000+01:00I agree that Enum should have method TryParse, but...I agree that Enum should have method TryParse, but I don't think the absence of the method violates an official guideline.<BR/><BR/>Moreover, TryParse is mainly for performance, less for debuggability, and definatelly not for simply avoiding exception handling.Anonymousnoreply@blogger.com