4 ms·
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 produ
by kuon 7y ago
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.
- jmkni 7y agoWhat's a good example of this sort of language?
- Latty 7y agoElm (https://elm-lang.org/ https://elm-lang.org/) is a language that compiles to JavaScript that doesn't have runtime exceptions.
- jmkni 7y agoNeat, thanks
- codenirvana 7y agoThere's Elm, PureScript and many other functional programming inspired languages. But, TypeScript is a safe bet.
- iraldir 7y agoIt 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.
- h1d 7y agoWhy 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.
- ShinTakuya 7y agoThe 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.
- jwilliams 7y agoI 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.
- brlewis 7y agoThe 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.
- specialist 7y agoMy 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.
- erik_seaberg 7y agoJava 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.