tag:blogger.com,1999:blog-9620948.post8907929228615725067..comments2023-10-20T12:24:17.734-07:00Comments on Binstock on Software: Banishing Return Status CodesAndrew Binstockhttp://www.blogger.com/profile/16321156191558412680noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-9620948.post-54994337817707809802008-10-07T14:41:00.000-07:002008-10-07T14:41:00.000-07:00(this is anonymous)Thank you for exactly understan...(this is anonymous)<BR/><BR/>Thank you for exactly understanding my point: to wit: it's exactly the same. If you want to handle "situations" in your code, you have to handle them. <BR/><BR/>Except that with exceptions (at least in C++), if every single resource allocated on a scope doesn't have an explict RAII type handler, you are bound to leak those resources.<BR/><BR/>If you don't want to handle them, then having status code is clearer.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-36702721576894658712008-09-30T12:40:00.000-07:002008-09-30T12:40:00.000-07:00@anonymous. I trust you're kidding. The problem is...@anonymous. I trust you're kidding. The problem is exactly the same with a return code. You have to some similar logic (presumably a switch statement with lots of cases) to distinguish the types of error the status code can report.Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-35802042680131751612008-09-29T23:30:00.000-07:002008-09-29T23:30:00.000-07:00"Exceptions are for exceptions: events that you do...<I>"Exceptions are for exceptions: events that you do not expect to occur on a regular basis. You should not use exceptions in place of return codes for normal processing due to the extra overhead and performance penalty of exceptions."</I><BR/><BR/>What about language features that are designed specifically to use exceptions in the normal course of events? Such as when your iterator throws StopIteration to tell you that it is done iterating?Tracy Reedhttps://www.blogger.com/profile/13238889740398567635noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-76953403560575158482008-09-29T11:42:00.000-07:002008-09-29T11:42:00.000-07:00With any discussion like this, it would also be go...With any discussion like this, it would also be good to reference the Null object design pattern, which eliminates any Null references at runtime. No need to check for Null if you design a system to never encounter it.Brandon Corfmanhttps://www.blogger.com/profile/01765211985760464677noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-39502350329834653672008-09-29T09:38:00.000-07:002008-09-29T09:38:00.000-07:00Yes, this is so much clearer:try{GetDataFromDataba...Yes, this is so much clearer:<BR/><BR/>try<BR/>{<BR/>GetDataFromDatabase();<BR/>}<BR/>catch FileNotFound<BR/>{<BR/>...<BR/>}<BR/>catch NoSuchIndex<BR/>{<BR/>...<BR/>}<BR/>catch InvalidUser<BR/>{<BR/>...<BR/>}<BR/>catch BadPermissions<BR/>{<BR/>...<BR/>}<BR/>catch DoesntWorkWithOracle<BR/>{<BR/>...<BR/>}<BR/>catch NotConnectedToNetwork<BR/>{<BR/>...<BR/>}<BR/>catch NetworkFailure<BR/>{<BR/>...<BR/>}<BR/>catch NotUsingAMac<BR/>{<BR/>....<BR/>}Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-22388414996312527962008-09-29T06:55:00.000-07:002008-09-29T06:55:00.000-07:00You might say a better rule would be "banish retur...You might say a better rule would be "banish return status codes and use exceptions <I>if</I> your language is poor enough not to offer a suitable alternative".<BR/><BR/>The Java case of NULL return codes indicating an error is a case in point. Java doesn't have a powerful enough type system to express types which can or cannot be nil. In a decent language you can force the programmer to handle the error return code, eg:<BR/><BR/>type t = Success of result | Error of detail<BR/><BR/>val f : arg -> t<BR/><BR/>match f with<BR/>| Error detail -> (* got to handle the error *)<BR/>| Success result -> (* next operation *)<BR/><BR/>(And you can simplify the above code further and make handling the error even more forceful, using monads, but I won't go there for now).<BR/><BR/>Note that this is distinctly different from C, where it's very easy to ignore a return code from a function, or Java/Python/etc. where nothing forces you to catch the exception.Richard Joneshttps://www.blogger.com/profile/08315526595922432607noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-46150379520978353832008-09-29T06:49:00.000-07:002008-09-29T06:49:00.000-07:00Exceptions are for exceptions: events that you do ...Exceptions are for exceptions: events that you do not expect to occur on a regular basis. You should not use exceptions in place of return codes for normal processing due to the extra overhead and performance penalty of exceptions.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-91550263893423408742008-09-29T00:36:00.000-07:002008-09-29T00:36:00.000-07:00I concur with jessta, the Maybe type is pretty sli...I concur with jessta, the Maybe type is pretty slick. The basic idea is that you can roll your status code and actual return value together into one, and then unpack it on the other side. It forces you to deal with the return code, because you have to consciously do the unpacking. The Maybe type attempts to cut down on code bloat by providing the monad bind (>>=) operation which basically does the thing you normally do with unhandled exceptions, which is to let them bubble up the stack. I'm hacking C now, and the lack of a way to bubble failure up the stack is driving me nuts with all the boilerplate.Reid Khttps://www.blogger.com/profile/10131127807440335781noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-7766731801889370592008-09-28T23:15:00.000-07:002008-09-28T23:15:00.000-07:00I like haskells way of returning the status of an ...I like haskells way of returning the status of an operation. In Haskell a function that may fail will return a value of type class Maybe. <BR/>http://en.wikibooks.org/wiki/Haskell/Hierarchical_libraries/MaybeJesstahttps://www.blogger.com/profile/06837651109419168637noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-52885186782822983952008-09-28T23:07:00.000-07:002008-09-28T23:07:00.000-07:00This is one of those posts on coding practices tha...This is one of those posts on coding practices that comes along every once in a while that attempts to convince everyone that we should all abandon our ways in favor of a "better" methodology. (I'm guilty of this type of post, too, so I understand where the author is coming from)<BR/><BR/>Unfortunately, nothing like that will ever occur because sometimes returning an error code is handy.<BR/><BR/>That's not meant to negate the effectiveness of a good try catch, of course, but you have to look at each situation in its own way and code based off of its requirements during that time and for the future.<BR/><BR/>This argument is similar to the JavaScript argument that since innerHTML isn't part of or using the DOM specifications, we should all spend our days coding DOM manipulations instead of a quick-and-dirty innerHTML.<BR/><BR/>Sometimes quick-and-dirty isn't all that dirty.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-31026846165294877382008-09-28T22:32:00.000-07:002008-09-28T22:32:00.000-07:00@droberts: Good advice!@davidw: Yes, right. My pos...@droberts: Good advice!<BR/><BR/>@davidw: Yes, right. My post is general advice. The example contexts you discuss are special circumstances where, I agree, return codes would serve better. There is, as you state, a cost in both performance and complexity for exceptions that can be excessive in tight loops or complex contexts.Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-79883361841393414862008-09-28T22:23:00.000-07:002008-09-28T22:23:00.000-07:00dave w. is probably talking about google's codebas...dave w. is probably talking about google's codebase, and he's right. exceptions are disallowed and most errors are raised through return codes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-90302803247251504382008-09-28T21:53:00.000-07:002008-09-28T21:53:00.000-07:00Herein lies madness. When I first moved to Python ...Herein lies madness. When I first moved to Python (around 2001) I shared a similar belief to the somewhat flawed one you hold now. After joining a corporation that will remain nameless I had this shaken firmly out of me, for (at a minimum) the following reasons:<BR/><BR/>- The use of exceptions introduces a whole new control flow that many developers, experienced and newbie alike, rarely think about until their production code explodes. Theoretically Java deals with this through checked exceptions, but <A HREF="http://www.artima.com/intv/handcuffs.html" REL="nofollow">therein dragons lie</A>.<BR/><BR/>- Performancewise, every practical exceptions implementation favours the "unexceptional" case and greatly punishes the exceptional case. Stack unwinding code is not something you want to run in an inner loop of your millions-of-transactions-per-second application.<BR/><BR/>There are many examples of methods that may fail and produce no useful result, even when 50% or more of their typical input data will cause them to fail. As a poor example, consider a function that accepts freeform text which may be treated as some integer ID or a substring to be matched. The work involved in testing for a valid integer is only slightly less than the work involved in parsing that integer. In my hypothetical millions-of-tps system, these kind of optimisations often become important.<BR/><BR/><BR/>- There is nothing particularly wrong with signalling completion status using the return value of a procedure; indeed there is greater asymmetry in signalling failure using a completely different mechanism.<BR/><BR/>An addend to this is that there is nothing particularly right about using the type system to classify error codes; "is-subclass-of" and "is-integer-equal" are no better than each other, except in the case where a procedure is returning very rich error information. In that case the procedure likely has an interface problem.<BR/><BR/><BR/>In principle I like the idea, but after observing the success of a modern Java/C++ code base whose size I am unlikely to see paralleled again in my lifetime (and which you are very likely to use every day of your life), I have to disagree.<BR/><BR/>Love the blog! :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-82382447393522503572008-09-28T21:48:00.000-07:002008-09-28T21:48:00.000-07:00Exceptions should be reserved for exceptional circ...Exceptions should be reserved for exceptional circumstances and not be used in normal flow of operation.<BR/><BR/>Look it up.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-76233499189739992302008-09-28T20:11:00.000-07:002008-09-28T20:11:00.000-07:00Or, even better, return this, thus allowing call c...Or, even better, return this, thus allowing call chaining...Anonymoushttps://www.blogger.com/profile/07555989787959778978noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-8890903966668001052008-09-28T20:00:00.000-07:002008-09-28T20:00:00.000-07:00If the user searches the database, and no result i...If the user searches the database, and no result is found, nothing bad happened, so an exception is not the best OO solution.<BR/>Create a static object, named NO_RESULTS_FOUND, of the base type object and return that.<BR/>No exception handling and no null return value.<BR/>(Effectively it is a null, but this may make the most orthodox OO fanatics happy)Anonymousnoreply@blogger.com