9 ms·

Sure, and then you have no idea what was executed and what failed. Did you run 9 functions or 1? What do you need to roll back? How do you handle the error? T

Sure, and then you have no idea what was executed and what failed. Did you run 9 functions or 1? What do you need to roll back? How do you handle the error? This is the problem with exceptions. They make it too easy to be lazy with your error handling.... Most of the time it's just catch and log, because the code itself has no way of knowing what failed and what succeeded. This is how you get your program in a bad state.... Because maybe you uploaded the file but didn't set the metadata in the API, because the connection broke between those steps. With go's error handling it forces you to think about "what happens if the code fails here". Its always obvious what code had been executed and what has not. To get that behavior in exception oriented languages, you'd have to wrap every call in try/catch, which ends up just as verbose as go, if not worse.

masklinn 9y ago
> Sure, and then you have no idea what was executed and what failed. Did you run 9 functions or 1? What do you need to roll back? How do you handle the error? > […] > With go's error handling it forces you to think about "what happens if the code fails here". Did it run 9 functions or just 1? What do you need to roll back? How do you handle the error? The inner code could have just bubbled an error by hand from a deeper call (or the library could even have used panic/recover internally to do so, the stdlib used to do that). You have no more idea than in the exceptions-based code unless you have the source available right there, which you'd then also have in an exceptions-based language. > To get that behavior in exception oriented languages, you'd have to wrap every call in try/catch, which ends up just as verbose as go, if not worse. So your argument in support of Go's error handling is that the very worst case of exceptions-based error handling you can imagine is about as bad as the baseline case of Go's?
erik_seaberg 9y ago
"What failed?" is recorded in the exception, along with the stack trace of how we got there. try...finally can perform best-effort cleanup, it's just like "defer" with block scope that fits the rest of the language. But it's not that unusual for server hardware to abruptly die, and no error handler can recover from that. "Uploaded file but didn't set metadata" has to be handled in the design phase. Another server needs to notice there may be some unfinished work (often by retrying idempotently).

masklinn 9y ago

> Sure, and then you have no idea what was executed and what failed. Did you run 9 functions or 1? What do you need to roll back? How do you handle the error? > […] > With go's error handling it forces you to think about "what happens if the code fails here". Did it run 9 functions or just 1? What do you need to roll back? How do you handle the error? The inner code could have just bubbled an error by hand from a deeper call (or the library could even have used panic/recover internally to do so, the stdlib used to do that). You have no more idea than in the exceptions-based code unless you have the source available right there, which you'd then also have in an exceptions-based language. > To get that behavior in exception oriented languages, you'd have to wrap every call in try/catch, which ends up just as verbose as go, if not worse. So your argument in support of Go's error handling is that the very worst case of exceptions-based error handling you can imagine is about as bad as the baseline case of Go's?

erik_seaberg 9y ago

"What failed?" is recorded in the exception, along with the stack trace of how we got there. try...finally can perform best-effort cleanup, it's just like "defer" with block scope that fits the rest of the language. But it's not that unusual for server hardware to abruptly die, and no error handler can recover from that. "Uploaded file but didn't set metadata" has to be handled in the design phase. Another server needs to notice there may be some unfinished work (often by retrying idempotently).