undefined | Better HN

0 pointsPudgePacket6y ago0 comments

... catch the errors?

0 comments

carlmr6y ago

It was rhetorical and meant to be facetious.

hombre_fatal6y ago

On HN it's better to just share your point rather than obfuscate it with sarcasm and rhetoric.

novaleaf6y ago

on 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.

spion6y ago

I 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.

1 more reply

carlmr6y ago

Yeah, 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.

j / k navigate · click thread line to collapse

0 comments

carlmr6y ago

It was rhetorical and meant to be facetious.

hombre_fatal6y ago

On HN it's better to just share your point rather than obfuscate it with sarcasm and rhetoric.

novaleaf6y ago

on node, this can actually be very difficult or even impossible if using 3rd party libraries.

I'm all for deno being built from the ground up to properly crash on uncaught errors. Silent ignoring is a really stupid decision.

spion6y ago

1 more reply

carlmr6y ago

Yeah, 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.

j / k navigate · click thread line to collapse