You Can Throw() Anything in JavaScript – and Other Async/Await Considerations

Re:You Can Throw() Anything in JavaScript – and Other Async/... by onion2k on Friday April 08, 2022 @11:44AM (#30958668)

When Dijkstra wrote his article [1], in 1968, I have no doubt he was correct. His point was essentially that code should reflect the flow of the application as closely as possible because it's immensely hard to keep everything in your head if it doesn't in the context of programming in 1968.

The thing is though, tools have moved on in the past 54 years. Seeing the flow of your code is a lot easier now. Debuggers are amazing things.

While I think his broad point (that code should be as simple and easy to follow as possible) still stands I don't really agree with it here. "goto considered harmful" could be used to argue that anything that changes and obfuscates the flow of a program when you compare the source to the compiled output is bad regardless of what it is, and that's plain silly. We'd have to throw away all manner of useful things like exceptions, macros, inheritance, etc.

I like Dijkstra's writing a lot, and he did groundbreaking work, but we have to remember to consider everything in the context of when it was written. This is a good example of that.

[1] http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...

[ Parent | on HN ]

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.

1. https://softwareengineering.stackexchange.com/questions/1892...

[ Parent | on HN ]