Most importantly, if any callback or handler throws an exception, this shouldn't corrupt the internal implementation details of tink_core primitives (such as CallbackList), resulting in lasting breakage (as in the try-haxe sample program above).
"Bad" callbacks/handlers shouldn't ruin life for everyone else (other callbacks/handlers). Until this PR, you can have add one faulty unimportant callback/handler which has a bug, and it has the potential to break the whole application if it throws.
Any other similar places that could benefit from such error-proofing?
P.S. I now remember suggesting this:
https://github.com/haxetink/tink_core/issues/165
Having been bitten by this problem again (when a signal handler throws), I couldn't wait any longer and came up with this limited solution. I don't see any reason not to do this by default, because I think this fixes an actual library bug, but since it can be kind of a breaking change, maybe it should be on an opt-in basis (conditional compilation flag).
to prevent this kind of shit: https://try.haxe.org/#50b2a5Ce
The main idea behind this PR:
Any other similar places that could benefit from such error-proofing?
P.S. I now remember suggesting this: https://github.com/haxetink/tink_core/issues/165 Having been bitten by this problem again (when a signal handler throws), I couldn't wait any longer and came up with this limited solution. I don't see any reason not to do this by default, because I think this fixes an actual library bug, but since it can be kind of a breaking change, maybe it should be on an opt-in basis (conditional compilation flag).