Remix.run Logo
liotier a day ago

Unsure if this is the right place to ask, but this conversation inspires me this question:

Is there in practice a significant difference between try/catch and Go's "if err" ? Both seem to achieve the same purpose, though try/catch can cover a whole bunch of logic rather than a single function. Is that the only difference ?

slau a day ago | parent | next [-]

Try/catch can bubble through multiple layers. You can decide/design where to handle the errors. If you don't `if err` in Golang, the error is skipped/forgotten, with no way to catch it higher up.

theshrike79 a day ago | parent | prev | next [-]

You can decide not to catch a thrown exception, it travels upwards automatically if you don't catch it.

I think that's the biggest difference.

With Go you need to specifically check the errors and intentionally decide what to do, do you handle it right there or do you bubble it upwards. If you do, what kind of context would the caller want from this piece of code, you can add that too.

stouset a day ago | parent | next [-]

> With Go you need to specifically check the errors and intentionally decide what to do, do you handle it right there or do you bubble it upwards.

Is this really all that interesting or worth the LOC spent on error handling when 99.9999% of the time in practice it’s just bubbled up?

And any “context” added is just string wrapping. Approximately nobody types golang errors in a way that lets you programmatically know what went wrong, to be able to fix it in-line.

I think I would be more empathetic to the arguments defending golang here if I’d ever worked or seen a project where people actually handled errors instead of spending 2/3 of their time writing code that just punts on any error.

LinXitoW a day ago | parent | prev [-]

I'd argue that at least checked exceptions also require a conscious decision from you. You either need to add the Exception type to your throws clause, or your catch clause.

Compared to Go, this is actually better because the type system can tell you what kind of errors to expect, instead of just "error".

Too a day ago | parent | prev [-]

“if err” doesn’t catch all types of errors. Some errors are colored different from others and instead cause the program to immediately crash, sorry panic. But don’t worry! it’s just very rare errors, like nil dereference and index out of bounds, that throw unrecoverable errors like this!