4 ms·
RAII can get rid of that one try/finally, that's true. I was writing standard Java/C#/Python-eque code, however, which requires all those try/catches. Here's
by NateDad 12y ago
RAII can get rid of that one try/finally, that's true. I was writing standard Java/C#/Python-eque code, however, which requires all those try/catches.
Here's what you get if you have some magic RAII file-closer object:
try {
f = os.Open(filename)
}
catch(Exception e) {
throw new Exception(string.Format("Failed to open config file: %s", e.Message))
}
try {
callFunctionThatMightErrorOut()
}
catch(Exception e) {
// handle error
}
Still not great.
- dllthomas 12y agoSure, and of course RAII can be of benefit either way. I'm not a pro-exceptions partisan, just don't like extraneously ugly code in examples. :-P
- NateDad 12y agoHaha, fair enough. But I was trying to write standard code that you'd see in many popular languages, whose proponents often complain about Go's error handling.
- dllthomas 12y agoFor sure. What I don't like about go's error handling is that it's product, not sum. That's a small objection, though.
- dragonwriter 12y ago> I was writing standard Java/C#/Python-eque code, however, which requires all those try/catches. No, it doesn't; wrapping each function call that might throw an exception in its own try/catch is recognized as an antipattern in all of those languages. Most likely, you'd want to do one try block, with possibly multiple catch blocks for more specific exceptions (but only if you can do something useful to handle those exceptions), although, really, if you are reading a configuration file and the function you are writing can't do anything meaningful with errors but rethrow them, you probably want something more like (and this would be a case for catching generic Exception): try { f = os.Open(filename) callFunctionThatMightErrorOut() . . . } catch(Exception e) { throw new FailedToReadConfigFileException(e) }
- NateDad 12y agoExcept that the caller can't tell what failed - was it file.Open, or was it callFunctionThatMightErrorOut? They both just cause the same FailedToReadConfigFileException, so you've made it impossible for the caller to react differently to each failure. In addition, they may even throw the same type of error (FileNotFoundException, for example), which may make it hard even for a human looking at the error to understand what actually failed, without looking at the stack trace and going into the code (which should be a last resort).
- dragonwriter 12y ago> Except that the caller can't tell what failed - was it file.Open, or was it callFunctionThatMightErrorOut? The caller knows that the function they called failed, and has as much detail from the underlying error as it makes sense to include in the special case Exception constructed from it. > They both just cause the same FailedToReadConfigFileException No, they cause the same class of exception. The data in that Exception can vary as much as necessary based on the data in the underlying exceptions thrown. Yes, if you actually have a need to differentiate, you may need additional try/catches, but that's usually a violation of encapsulation that exposes internal implementation details of a method to calling code, which defeats much of the purpose of OO, or even merely structured, programming.