Timeline for Using return value vs out parameters
Current License: CC BY-SA 3.0
28 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 1, 2012 at 8:06 | comment | added | Konrad Rudolph | @Winston Hmm. I’m having a hard time making a case here since file operations in C++ work exception-free just fine. I thought I had understood Eric’s argument. | |
| Mar 1, 2012 at 0:39 | comment | added | Winston Ewert | @KonradRudolph, but you could have OpenFile return null if opening fails and have boolean error codes on methods like read/write. I still don't see a difference. I could absolutely use error codes on file operations and still handle all those cases correctly. What's being contrasted there isn't exceptions vs error codes, but look before you leap vs ask for forgiveness. | |
| Mar 1, 2012 at 0:32 | comment | added | Konrad Rudolph | @Winston Because file access can fail at every moment and you have no way of checking this, since the file system is inherently concurrent and non-transactional. For instance, there is no way (!) to reliably check whether a file exists and to work with that information, since immediately after the check the information obtained is obsolete. This is the relevant difference. | |
| Feb 29, 2012 at 22:50 | comment | added | Winston Ewert | @KonradRudolph, ah, true. I guess I don't see those categories as distinct as he does. Opening a file could return null just like TryParse can return false. I don't really see why he thinks they are in a different category. | |
| Feb 29, 2012 at 22:39 | comment | added | Konrad Rudolph | @Winston SendMail isn’t a case of vexing exceptions though. It’s the “exogenous” type in his taxonomy, and the whole raison d’être for exceptions. | |
| Feb 29, 2012 at 22:34 | comment | added | Winston Ewert | @KonradRudolph, certainly option types would solve the case of parseInt but what about sendEmail? sendEmail wouldn't have a return value of interest but we'd still like to enforce the check. However, I'm sure a good solution can be found to that problem as well. I don't think exceptions are perfect, I just think they are better then returning error codes. I have to agree that catching exceptions can require more code (albeit depends a bit on language/exact context). I think enforcing the check is worth it. | |
| Feb 29, 2012 at 22:22 | comment | added | Konrad Rudolph | @Winston That said, your arguments are good enough that I would post them as comments on Eric’s blog post. | |
| Feb 29, 2012 at 22:19 | comment | added | Konrad Rudolph | @Winston I agree about enforcing the check, which is why an option type is a better solution here – it lets the check be enforced by the type system. To some extent the same is true for values where you are sure that they are correct. “What advantage is there in using an error code over an exception?” – Less boilerplate code. | |
| Feb 29, 2012 at 22:15 | comment | added | Winston Ewert | Additionally, almost no function should always be in a try/catch. For example, a parseInt function could be used on input which I'm already sure is a valid integer. If that's the case and a letter somehow got into my string, I want the exception behavior, to report the error up because I've got a bug not the error code behavior which will just carry on and mask the real cause of the bug. Now, to turn the whole question around, what advantage is there to using an error code over an exception? | |
| Feb 29, 2012 at 22:14 | comment | added | Winston Ewert | @KonradRudolph, actually I think there still is an objective advantage of an exception over a boolean return value. If I fail to check my boolean return code my program will silently fail which is very bad. If I fail to catch an exception, my program will probably die, which is not good but a lot better then a silent failure. | |
| Feb 29, 2012 at 21:56 | comment | added | Konrad Rudolph | @Winston “Think of it this way: if you need to always put a try block around a call, then exceptions aren’t appropriate here. They are only appropriate when the caller can usually skip the try and let exceptions bubble up.” The point being: if you always have to catch exceptions (as you would have to in the case of input checking) they have no objective advantage over a boolean return value. The whole point of exceptions, their design goal, is the ability to be caught way up the call stack. | |
| Feb 29, 2012 at 21:05 | comment | added | Winston Ewert | @KonradRudolph, what evidence have you presented for you position? The only thing I see is the claim "exceptions are for exceptional circumstances" without any reason given for that. Fair enough, I haven't presented any either. I'd say that I prefer exceptions because they have a sane(r) default then error codes. But I'll agree something else perhaps monads would be even better, but sadly not supported in enough languages. | |
| Feb 29, 2012 at 20:21 | comment | added | Konrad Rudolph | @Winston I’m observing that you – unlike Eric and me (see above!), in fact – don’t provide any evidence for your position either, merely reiterating your position. Of course “error returns” are an almost as bad way of handing this case. A good design would have used monads (more specifically, option values). | |
| Feb 29, 2012 at 20:15 | comment | added | Winston Ewert | @KonradRudolph, Eric Lippert is wrong. As far as I'm concerned exceptions are a much better way to handle what he calls "vexing" exceptions then error returns are. Of course, you and Eric can disagree with me. The thing is that you neither you nor Eric provide reasoning for why you think exceptions are bad for these cases, you merely reiterate the position that they are. | |
| Feb 23, 2012 at 13:34 | comment | added | ANeves | @MrHappy I would not; but that doesn't mean stream != null, which is not supposed to happen in normal situations. My point is that my calling methods should only get exceptions that are the responsibility of (or consequences of) either them or someone in an outer scope; so if they are sure that all arguments passed to SendEmail are valid and the method returns no resource, my rationale is that I should not need to wrap the calls in try-catches. It feels wrong. IMO external methods should not have to be aware of InvalidSMTPSSLTokenException or whatever - only SendEmail. | |
| Feb 23, 2012 at 13:15 | comment | added | dvdvorle | @ANeves Would you also like a bool TryOpenFile(string fileName, out File stream){}? | |
| Feb 23, 2012 at 13:11 | comment | added | ANeves | @MrHappy sorry for the belated reply. I think you make a good point, but I disagree; I would have a mixed approach - as an example, throw if the current state did not allow the action and return false if the conditions were not met. I much prefer bool TrySendEmail(...){} to a void-returning that throws an exception. (I might still throw from inside TrySendEmail, if for example a null address was supplied.) | |
| Feb 23, 2012 at 12:41 | comment | added | Konrad Rudolph | @MrHappy But this isn’t what exceptions are good at. They are good at indicating exceptional conditions that don’t necessarily have to be handled by the caller, but instead passed on to higher levels. This is never true when parsing input. Faulty input should always be handled straightaway. Think of it this way: if you need to always put a try block around a call, then exceptions aren’t appropriate here. They are only appropriate when the caller can usually skip the try and let exceptions bubble up. Read Eric Lippert’s explanation that I linked above. | |
| Feb 23, 2012 at 11:42 | comment | added | dvdvorle | @KonradRudolph I agree that you always need to validate input. I'm saying that invalid input is an exceptional condition. I always code as if everything is valid, and handle the exceptional cases in seperate blocks, namely the catch clauses. | |
| Feb 23, 2012 at 10:58 | comment | added | Konrad Rudolph | @MrHappy User input is inherently untrusted. Since you always need to perform validation, the validation isn’t an exceptional condition. You are expecting potential failure. I’m not saying that TryParse is optimal (it’s not, the entire interface sucks) – there are much better ways of modelling this but C# supports them poorly. | |
| Feb 23, 2012 at 10:45 | comment | added | dvdvorle | @KonradRudolph Hmm I didn't know that (good article btw). Allright bad example, but I think my point still stands. Invalid input is an exceptional condition, for which an Exception should be thrown, not a false returned. Unless TryDoSomething([some args]) is actually a TryParseSomething(out [some args]) | |
| Feb 23, 2012 at 10:21 | comment | added | Cristian Lupascu | I agree with this only for trivial cases, like the TryParse method, where the meaning of the output is well-known. I certainly wouldn't build an application full of methods starting with Try that return bool. | |
| Feb 23, 2012 at 10:11 | comment | added | Konrad Rudolph | @MrHappy Nonsense, TryParse is not there for performance reasons. Rather, it was retrofitted once they saw that throwing an exception when parsing is highly inappropriate. Eric Lippert acknowledges that int.Parse was an “unfortunate design decision”. | |
| Feb 23, 2012 at 10:05 | comment | added | Mattias | Totally agree. +1 | |
| Feb 23, 2012 at 9:07 | comment | added | dvdvorle | @AdamRobinson: Tell Microsoft that. int.Parse and int.TryParse are prime examples. TryParse is only here because of performance reasons. Should I check that the string I want to parse only contains characters that can be converted to numbers? No I expect my input to be valid. If it's not valid, that is an exceptional condition, and a FormatException will be thrown by int.Parse which I can handle in a seperate catch clause. I can't miss an exceptions, whereas I can miss a boolean return value. | |
| Feb 23, 2012 at 3:42 | comment | added | Adam Robinson | @MrHappy: Exceptions absolutely are not meant for this. Exceptions are meant for exceptional conditions, meaning they are conditions that should not normally occur while your program is executing. Your code should always preemptively check to see if the data is valid. Exceptions are not meant to serve as lazy validation routines. | |
| Feb 22, 2012 at 23:11 | comment | added | dvdvorle | Please don't use this. Exceptions are meant for this. If you're worrying about performance because of Exception creation check the preconditions before calling this method. | |
| Feb 22, 2012 at 17:43 | history | answered | ANeves | CC BY-SA 3.0 |