4 ms·

Whether you want to handle every error is context dependent. StatusIM has long running servers & clients as primary products and so tilt away from exceptions,

by cb321 2y ago

Whether you want to handle every error is context dependent. StatusIM has long running servers & clients as primary products and so tilt away from exceptions, but for a CLI utility you might want the convenience of a stack trace instead. I've seen this many times in Python CL apps, for example. Alternatively, there is also a Nim effects tracking system that lets the compiler help you track the hidden control flow for you. So, at the top of a module, you can say {.push raises: [].} to make sure that you handled all exceptions somewhere. So, it may not be as "Wild West" as other exceptions systems that you are used to. As with so many aspects, Nim is Choice. For many choice is good. For others they want language designers to constrain choice a lot (Go is probably a big recent example, because fresh out of school kids need to be kept away from sharper tools or similar rationales). A lot of these prog.lang. battles mirror bigger societal debates/divides between centralized controls and more laissez-faire arrangements. Nim is more in the Voltaire/Spiderman's Uncle Ben "With great power comes great responsibility" camp, but how much power you use is usually "up to you" (well, and things you choose to depend upon).

zamalek 2y ago
> {.push raises: [].} Will this transitively enforce exception handling? i.e. if a 3rd-party dependency that I am using calls into another dependency that raises exceptions, but doesn't handle them in any way (including not using that pragma), will Nim assert that? Otherwise, that's precisely the function coloring problem I mentioned: if you can't statically assert that a callee, or it's descendant callees, doesn't throw an exception then you have to assume that it will.
- cb321 2y ago
  > Will this transitively enforce exception handling? Yes. The module you put the pragma in is about the "roots" of the call graph, but it covers the whole call stack from those roots down wherever the code is defined. Sorry I didn't make that clear enough { but in my defense I was trying to address the problem you raised. :-) }
  - zamalek 2y ago
    I'll be taking another look at Nim :)
    - cb321 2y ago
      Cool. BTW, you may want to not assume something is impossible before asking questions on the Nim Forum (https://forum.nim-lang.org/ https://forum.nim-lang.org/) or their discord IRCs. An awful lot is possible with this-or-that pragma or macro, but discovery of features & approaches is an eternal challenge with docs (in many realms, really, not even "just prog.langs").

by cb321 2y ago

zamalek 2y ago

> {.push raises: [].} Will this transitively enforce exception handling? i.e. if a 3rd-party dependency that I am using calls into another dependency that raises exceptions, but doesn't handle them in any way (including not using that pragma), will Nim assert that? Otherwise, that's precisely the function coloring problem I mentioned: if you can't statically assert that a callee, or it's descendant callees, doesn't throw an exception then you have to assume that it will.

cb321 2y ago
> Will this transitively enforce exception handling? Yes. The module you put the pragma in is about the "roots" of the call graph, but it covers the whole call stack from those roots down wherever the code is defined. Sorry I didn't make that clear enough { but in my defense I was trying to address the problem you raised. :-) }
- zamalek 2y ago
  I'll be taking another look at Nim :)
  - cb321 2y ago
    Cool. BTW, you may want to not assume something is impossible before asking questions on the Nim Forum (https://forum.nim-lang.org/ https://forum.nim-lang.org/) or their discord IRCs. An awful lot is possible with this-or-that pragma or macro, but discovery of features & approaches is an eternal challenge with docs (in many realms, really, not even "just prog.langs").