Hacker News Reader

Comment by kuon | Hacker News Reader

The part about parameter less catch reveals a lot about the philosophy of the language. For me, silencing error like this is a bad practice. You may still produce a sane error in the catch, but the design goes toward silencing things.

I really love languages that force you to handle errors up to the top level.

View on HN

It does, though I wouldn't go to the same conclusion. It gives more freedom to the developer. They are lot of cases where errors are in fact, expected. Parsing a user inputted JSON. Making a request to check internet connection availability. Any promise that is going to be consumed by an async - await pattern. In those cases (and many more), you may want to try something just simply to see if it works. It's completely different say to being on the backend, trying to write to a database which may or may not fail.

In those cases, forcing the extra parameter in the catch, even though you are not using it, is slightly annoying. I mean it's literally 3 characters, but in this age of linters encouraging to not specify arguments you don't use, it just feels unnatural.

The problem is that the catch block will catch all errors, so if a different type of error to the one you expected occurs then it gets silently swallowed. This is the equivalent of catching the generic Exception class in python. Horrendous terrible practice in anything but the hackiest scripts.

Why would you ever want to ignore the error parameter?

I really hate when a system tells me "Unknown error occured" or "Either this or that happened" because the software doesn't care to be specific with the errors.

You should at least log the error message, not ignore it.

I see what you're saying - for me, my experience with Java checked exceptions put me off the idea.

In Java it led to lots of exception wrapping and leaky abstractions.

Not sure what the answer is - although my golang experience was better.

The answer is one of two possibilities: either make the IDE a little dumber and stop highlighting uncaught exceptions, or make the IDE a lot smarter and make it highlight when you catch an exception but don't do anything useful with it.

Java programmers need to be comfortable letting exceptions have the default behavior until they're sure they have a better idea. Declaring throws is usually enough.

My current best guess is Java's checked exception silliness comes from the enterprise framework culture. Too much abstraction, architecture, cleverness, turgidity. I joke that Spring is an Exception obfuscation framework.

I've always really liked checked exceptions in my own designs. Though I'm not crazy about the syntax.

Java blew it on generic exceptions.

  stream.map(f).collect(...)

should be able to throw anything f can throw, but instead f has to wrap everything, which makes people give up and stop declaring checked exceptions.

What's a good example of this sort of language?

Elm (https://elm-lang.org/) is a language that compiles to JavaScript that doesn't have runtime exceptions.

Neat, thanks

There's Elm, PureScript and many other functional programming inspired languages. But, TypeScript is a safe bet.

Reply on news.ycombinator.com