undefined | Better HN

0 pointsEdwardDiego3y ago0 comments

I like the reasoning behind Go's approach, but the `if err != nil` ends up polluting codebases like Java's checked exceptions did.

I'm not sure what the better way to do it is tbh.

0 comments

kaba03y ago

Java's checked exception's could be handled at a single place by a catch, or just marked as `throws`. It was never as verbose as go is.

EdwardDiegoOP3y ago

Maybe, but then, when Jackson is throwing an IOException because of bad JSON, and the file you opened that had the JSON could also throw an IOException, then it's not just catch it at a single place, as you'd generally handle both differently.

randomdata3y ago

> but the `if err != nil` ends up polluting codebases

Pollute implies that it is unwanted, but this is something you do want. It is the most interesting and important part of your application logic. You want it up front and centre for all to see.

I think we all understand the human desire to want to believe that bad things won't happen, but when one becomes an engineer they have to set those emotions aside and realize that bad things will happen and that your job is to make sure that when bad things do happen that the failsafes achieve an acceptable outcome.

> I'm not sure what the better way to do it is tbh.

I'm not sure any better is fundamentally possible within an engineering context. The vast majority of the job is in understanding the failure modes and being able to communicate to the computer how to gracefully deal with the problems when they occur. As such, it stands to reason that the vast majority of the code is going to be related to errors.

If you are programming for hobby/learning purposes, where when bad things happen your program can simply crash with no consequence, there are different approaches that work well, but Go is decidedly not designed for this space. And, frankly, doesn't need to be as there are already plenty of languages designed for that. Go is, quite explicitly, meant to be an engineering language.

peterashford3y ago

I can't agree with that at all. Checked exceptions can all be bubbled up to a single catch if that's how you want to handle it. That hardly pollutes a codebase.

EdwardDiegoOP3y ago

Sure. But the bubbling of checked exceptions adds a lot of "foo() throws DeepUnderlyingException", all the way up to your single catch.

And the worst part is when reading the code in such a situation, it can get very tricky to figure out exactly where the exception is thrown.

There's a reason that the JVM ecosystem has largely moved away from checked exceptions.

j / k navigate · click thread line to collapse

0 comments

kaba03y ago

Java's checked exception's could be handled at a single place by a catch, or just marked as `throws`. It was never as verbose as go is.

EdwardDiegoOP3y ago

randomdata3y ago

> but the `if err != nil` ends up polluting codebases

Pollute implies that it is unwanted, but this is something you do want. It is the most interesting and important part of your application logic. You want it up front and centre for all to see.

> I'm not sure what the better way to do it is tbh.

peterashford3y ago

I can't agree with that at all. Checked exceptions can all be bubbled up to a single catch if that's how you want to handle it. That hardly pollutes a codebase.

EdwardDiegoOP3y ago

Sure. But the bubbling of checked exceptions adds a lot of "foo() throws DeepUnderlyingException", all the way up to your single catch.

And the worst part is when reading the code in such a situation, it can get very tricky to figure out exactly where the exception is thrown.

There's a reason that the JVM ecosystem has largely moved away from checked exceptions.

j / k navigate · click thread line to collapse