News for hackers. Stuff that matters.
Re:A better way to handle errors in JavaScript by girvo on Tuesday October 31, 2023 @02:14AM (#38080929)
Indeed.

A fun example of this is Nim: “results” is quite a nice library, but Nim’s stdlib and by extension most of its third party libraries are built around exceptions (or std/options).

And Nim uses effect tracking, you can encode the exceptions raised into the type signature, so in some ways it’s perfectly poised for something like “results” or unwrapit

Yet when you try to go down that path (like we did at work, doing embedded firmware) it feels like you’re fighting against the current, sadly.

Re:A better way to handle errors in JavaScript by ghosty141 on Tuesday October 31, 2023 @03:35AM (#38081331)
I personally like the saying „when in rome, do as the romans do“. While you CAN retrofit almost anything to a lang, it tends to be a constant fighting against the current which is rarely worth it.

A good example is when working with Qt, trying to avoid QString and QObject as much as possible is a fools errand, its slower and ultimately ends up with ugly code.

Re:A better way to handle errors in JavaScript by sublinear on Tuesday October 31, 2023 @03:43AM (#38081385)
Try VTL