Re:You Can Throw() Anything in JavaScript – and Other Async/...
by smt88 on Friday April 08, 2022 @12:01PM
(#30958896)
> in the context of programming in 1968
I was only pointing out that this is essentially the "original sin" of programming.
It's hardly an issue we've moved beyond, though. It's still one of the most widely-discussed anti-patterns[1] that I've seen in my career. There are dozens of essays and articles saying the same thing.
> Seeing the flow of your code is a lot easier now. Debuggers are amazing things.
There are no tools in any IDE or debugger that make it easier to look at a `throw` line and know all the places it might be caught. It guarantees the need for runtime debugging.
It's actually theoretically impossible to see all `catch` candidates for any particular `throw` in JavaScript because the dynamic nature of the language makes it possible for almost any function to call any other function at runtime.
This is still true in JavaScript of, say, a function call, but a function call can be more certain that its caller will be prepared to handle its output (especially when using TypeScript). When a `catch` is written without knowing all the possible things that can be thrown at it, it's very likely something will be thrown that isn't handled in the catch.
I was only pointing out that this is essentially the "original sin" of programming.
It's hardly an issue we've moved beyond, though. It's still one of the most widely-discussed anti-patterns[1] that I've seen in my career. There are dozens of essays and articles saying the same thing.
> Seeing the flow of your code is a lot easier now. Debuggers are amazing things.
There are no tools in any IDE or debugger that make it easier to look at a `throw` line and know all the places it might be caught. It guarantees the need for runtime debugging.
It's actually theoretically impossible to see all `catch` candidates for any particular `throw` in JavaScript because the dynamic nature of the language makes it possible for almost any function to call any other function at runtime.
This is still true in JavaScript of, say, a function call, but a function call can be more certain that its caller will be prepared to handle its output (especially when using TypeScript). When a `catch` is written without knowing all the possible things that can be thrown at it, it's very likely something will be thrown that isn't handled in the catch.
1. https://softwareengineering.stackexchange.com/questions/1892...