Let me reply on the side for > 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.
I kind of disagree with that. Sure, in Go you have to write the error logic by yourself, but that's not difficult and it does not make the code so terrible to read. it gives you two benefits: * you can think about the errors and in some cases you might do extra cleanup in case of it you would surely have forgotten to write if you didn't set yourself to write the error handler * it makes for beautiful error messages. perhaps a bit verbose, but when you have an error, you know exactly what happened. > 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. What's the difference between the `asyncLog` you suggest and looping around `runForever` while logging errors? It seems pretty equivalent to me. In any case, an exception that goes down back to the async runner seems a bug to me. it might be useful to catch it to prevent the whole application from crashing, but it should be avoided and corrected if you see the error.
