5 ms·
... catch the errors?
by PudgePacket 7y ago
... catch the errors?
- carlmr 7y agoIt was rhetorical and meant to be facetious.
- hombre_fatal 7y agoOn HN it's better to just share your point rather than obfuscate it with sarcasm and rhetoric.
- novaleaf 7y agoon node, this can actually be very difficult or even impossible if using 3rd party libraries. For example, some node internals like networking require the invoker to attach to some obscure .on("error") event to avoid uncaught errors. and a lot of the time these 3rd parties are not aware of it. I'm all for deno being built from the ground up to properly crash on uncaught errors. Silent ignoring is a really stupid decision.
- spion 7y agoI never understood why this is necessary. Using promises means you get to use try-with-resources style construct for handling non-memory resources safely. As such you no longer need to crash on uncaught errors, except errors pertaining to resource disposal.
- novaleaf 7y agoi think the reason is that, in my example of networking, the network i/o is an "interupt" kind of event, that is triggered outside of normal execution. like if there's a socket timeout. probably didn't have to be designed this way, but it was designed pre-promises and I guess they are lothe to change it.
- carlmr 7y agoYeah, I'm a huge fan of erroring out properly. It makes it much easier to find problems before they cost money. I think the erlang/elixir model of fail fast and try to restart is the best for availability.