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
All this logic is heavily exception-raising oriented, which is suboptimal because it is very expensive in terms of performance to catch an exception, and second because it force the user wrap the calls in try except blocks which makes the code less readable.
I would consider making all these functions safe, relying on the return values to propagate errors. For example here the output could be an empty set if all actions are forbidden, or you can return a Union of Failure | ActionSet (same goes for the main predict() function, which could return a union of Failure | Prediction).
(This only applies to method-level validation. Validators that evaluate the instantiation of the class itself should still throw exception as it should not be possible to instantiate an invalid class)
All this logic is heavily exception-raising oriented, which is suboptimal because it is very expensive in terms of performance to catch an exception, and second because it force the user wrap the calls in try except blocks which makes the code less readable.
I would consider making all these functions safe, relying on the return values to propagate errors. For example here the output could be an empty set if all actions are forbidden, or you can return a Union of Failure | ActionSet (same goes for the main
predict()
function, which could return a union of Failure | Prediction).(This only applies to method-level validation. Validators that evaluate the instantiation of the class itself should still throw exception as it should not be possible to instantiate an invalid class)
Originally posted by @adarmiento in #35 (comment)
The text was updated successfully, but these errors were encountered: