You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the "safety" I was envisioning would involve not specifying the exception code in the ctor ... which would then imply that at least the tryTree would have to be a factory, not a pre-built tree, so the Catch ctor could pass the created code into that factory
fair point, also its almost like the tryTree should declare its possible ResultCodes and the overall tree should make sure all possible ResultCodes are handled. Like how Java handles exceptions
you could have some typescript voodoo for that...
though I think the number of generic type args you'd need in some places would get very hairy very fast
but I also figured that, in the context of a BT, it seems like you really have no business pretending you can catch things you don't know what are, and conversely you shouldn't be throwing things if you don't know what's going to happen with them
that to me seems like an argument to use TS voodoo, crazy typing be damned. I agree it could get out of hand though. I'd love to find the time to experiment with an implementation.
this might end up getting too verbose, but something like the following might help manage exception cases:
I'm not really sure what form the EXCEPTION_CODE would look like or how tryTree would know how to throw it - perhaps a specially monitored ResultCode?
The text was updated successfully, but these errors were encountered: