> I highlighted the line as an example of one of many lines in that code where > exceptions are raised, but are not caught. Not catching them leads to leaks > and/or crashes because of missing exception handlers / defer / whatever your > preferred handling mechanism is. If that is not problematic, I'm not sure > what is.
By that definition pretty much all lines are problematic since most of them can throw. Nim isn't Go and for a good reason, writing error propagation logic manually is a waste of time. > No, you ask that the exception is transferred to the function calling > runForever where it can be caught - this is a design issue with asyncCheck > which leads to poor error handling at best, and like you say, crashes at > worst. No, the whole point of `asyncCheck` is to ensure exceptions are not silently ignored and to kill your application if your code's exceptions aren't handled. This mechanism is not there so that you can catch the exceptions in `poll`. If you are catching these exceptions by wrapping `runForever` (or `poll`) with a `try`...`catch` then you're simply asking for trouble. I suppose I should have emulated a Rust `panic` and just called `quit` instead of raising. But really, you're making this out to be far worse than it is. Idiomatic async code always has a `poll`/`runForever`/`waitFor` at the top-level and it never checks for exceptions at the `poll` call, so your app will crash and that's by design. If you don't want it to crash then just define an `asyncLog` which logs the errors instead. Really this is something that should be defined for you in the stdlib, but since Nim's threading provides a way to override the default exception behaviour for threads maybe we should simply emulate this for async too to change what `asyncCheck` does.
