3 ms·

even if you wrap in try catch its worse because it moves the error to the bottom, messes with your scopes, and you can't tell which line actually threw

kaba0 4y ago
Or — you can wrap logical parts into a try-catch block, because it doesn’t really makes sense to throw 263 different errors for the same logical unit of work. Also, bubbling up is the sane default, even if you are writing a fast script/trying out some code it won’t clutter anything and you will be notified to handle the problems once you want to write robust code. While in Go you will just put empty if errs and will forget about the whole thing, swallowing errors which are arguably the worst thing.
- hdjrudni 4y ago
  Yes, wrapping individual statements is better. But then it's still overly verbose and has weird scoping issues. e.g. in JS you might write: try { let res = somethingThatMightFail(); catch(err) { // log the error or something return null; } // res is good now... but it's out of scope Whereas in C++ you'd just write ASSIGN_OR_RETURN(auto res, somethingThatMightFail()) And it will bubble your error status just like you wanted, only takes 1 line of code, and keeps all the error information (assuming you're using absl::Status). I haven't really used Go, but it sounds like the worst of both worlds. > even if you are writing a fast script/trying out some code it won’t clutter anything and you will be notified to handle the problems once you want to write robust code How are you going to go back and find every callsite that might potentially fail at a later date? There's no easy way to even tell if somethingThatMightFail might fail if it doesn't return something like a "StatusOr" or "Option" or something. I think Java has some tooling to force exception handling. Not sure about Go.
  - kaba0 4y ago
    Well, Java has checked exceptions which have to be handled at call site, or be declared as being thrown in the method handler (making it ‘viral’). I believe these solve this “find every callsite later” thing quite well. While Java’s exceptions are not without problems (too deep inheritance trees don’t make sense on exception types, lambdas not operate too well with this feature, etc), I think it is a really good direction not utilized to the full by any mainstream language.

kaba0 4y ago

Or — you can wrap logical parts into a try-catch block, because it doesn’t really makes sense to throw 263 different errors for the same logical unit of work. Also, bubbling up is the sane default, even if you are writing a fast script/trying out some code it won’t clutter anything and you will be notified to handle the problems once you want to write robust code. While in Go you will just put empty if errs and will forget about the whole thing, swallowing errors which are arguably the worst thing.

hdjrudni 4y ago
Yes, wrapping individual statements is better. But then it's still overly verbose and has weird scoping issues. e.g. in JS you might write: try { let res = somethingThatMightFail(); catch(err) { // log the error or something return null; } // res is good now... but it's out of scope Whereas in C++ you'd just write ASSIGN_OR_RETURN(auto res, somethingThatMightFail()) And it will bubble your error status just like you wanted, only takes 1 line of code, and keeps all the error information (assuming you're using absl::Status). I haven't really used Go, but it sounds like the worst of both worlds. > even if you are writing a fast script/trying out some code it won’t clutter anything and you will be notified to handle the problems once you want to write robust code How are you going to go back and find every callsite that might potentially fail at a later date? There's no easy way to even tell if somethingThatMightFail might fail if it doesn't return something like a "StatusOr" or "Option" or something. I think Java has some tooling to force exception handling. Not sure about Go.
- kaba0 4y ago
  Well, Java has checked exceptions which have to be handled at call site, or be declared as being thrown in the method handler (making it ‘viral’). I believe these solve this “find every callsite later” thing quite well. While Java’s exceptions are not without problems (too deep inheritance trees don’t make sense on exception types, lambdas not operate too well with this feature, etc), I think it is a really good direction not utilized to the full by any mainstream language.