I love static site generators, Elm, JavaScript and building things for the web.
In my previous life I was a working classical pianist. I try to combine music and programming when I can.
Languages like Go, Rust, and Haskell don't have exceptions and they figured out these problems.
I knew this article would ruffle feathers when I wrote it. I wanted to present an alternative approach. I prefer explicit handling of uncertainty rather than leaving escape hatches throughout the code.
Time has shown us that no matter how careful we are Java programs will eventually throw an uncaught nullexceptionpointer. We need better mental models not more disciplined programmers.
I was in agreement with you about handling uncertainty properly, and exceptions allow you to do exactly that.
The fact is, we will undoubtedly need to work with 3rd party libraries et al in our code. If the language supports exceptions, then we will need to handle them. It makes sense to use them if we need to handle them at some point anyway.
Plenty of incredibly popular and powerful languages use exceptions to handle errors, that's their solution to handling the error problem. If Go & Rust don't, that's fine, it doesn't make them bad languages or mean that exceptions are bad or to be avoided.
I love static site generators, Elm, JavaScript and building things for the web.
In my previous life I was a working classical pianist. I try to combine music and programming when I can.
My usual pattern with 3rd party libraries is to catch the exception immediately around the function call then convert it to a Result. Some functional libraries even have a helper function for this. See Purify's encase function gigobyte.github.io/purify/adts/Eit...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Languages like Go, Rust, and Haskell don't have exceptions and they figured out these problems.
I knew this article would ruffle feathers when I wrote it. I wanted to present an alternative approach. I prefer explicit handling of uncertainty rather than leaving escape hatches throughout the code.
Time has shown us that no matter how careful we are Java programs will eventually throw an uncaught nullexceptionpointer. We need better mental models not more disciplined programmers.
I was in agreement with you about handling uncertainty properly, and exceptions allow you to do exactly that.
The fact is, we will undoubtedly need to work with 3rd party libraries et al in our code. If the language supports exceptions, then we will need to handle them. It makes sense to use them if we need to handle them at some point anyway.
Plenty of incredibly popular and powerful languages use exceptions to handle errors, that's their solution to handling the error problem. If Go & Rust don't, that's fine, it doesn't make them bad languages or mean that exceptions are bad or to be avoided.
My usual pattern with 3rd party libraries is to catch the exception immediately around the function call then convert it to a
Result. Some functional libraries even have a helper function for this. See Purify's encase function gigobyte.github.io/purify/adts/Eit...