haxetink / tink_core

Core utilities
https://haxetink.github.io/tink_core
MIT License
117 stars 33 forks source link

Exception catching mode. #165

Open back2dos opened 3 years ago

back2dos commented 3 years ago

Via e.g. -D tink_core.catch_exceptions a few try/catch barriers would be added:

  1. in Promise.next/new/irreversible exceptions would be propagated as errors.
  2. In Callback.guardStackoverflow (which is where almost all dispatching goes through) any exceptions would be caught and reported, as well as all other places that call user code (e.g. CallbackLink.cancel).
  3. Add some Error.oncaught((e.Exception)->Void) where user can add errors reporters (if none are added, use console.error on JS and the closest possible thing on other platforms).
gene-pavlovsky commented 2 years ago

How is it going with this?

Meanwhile I made a small test program which checks how it works with both signals and observables. The results are more scary than I thought. If any signal handler / observable binding throws an exception, not only this prevents other handlers / bindings from being called with the current signal / state change, but none of the handlers/bindings ever run again on further signals / state changes.

exception-test.tar.gz

gene-pavlovsky commented 9 months ago

P.S. Adding exception handling to guardStackoverflow only makes sense if the code wrapped by it can survive an exception being thrown. E.g. if one of the cells in CallbackList.invoke throws, the object will be left in a bad state (with busy: true), regardless of any exception handling done by guardStackoverflow.

Otherwise I think the changes proposed in the issue description would be good to have ASAP :)