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
This is coming from glancing at the code changes in #237, specifically ebebb5f
I think it just makes sense to have a well named error class that informs the user that nothing actually went wrong, but Forest cannot continue with the data or parameters as they were provided.
My use case comes from running Forest on a server and needing to display a status page/message. If I can catch a couple Forest-specific error types I can show a custom message for each.
If something is ambiguous the developer can use exception chaining to preserve the original stack trace. (Exception chaining is just when you are inside a try-except and tack on a "from" argument like raise MyNewError("information") from source_error.)
I can immediately think of two exception types, Data and Parameter:
ForestDataError to be used in cases like the linked code above where we have data that cannot be used to run the tree.
ForestParameterError to be used when a parameter getting passed into tree function is somehow incompatible.
Are there any other scenarios or special cases where a new reserved exception type like those two would be useful?
The text was updated successfully, but these errors were encountered:
This is coming from glancing at the code changes in #237, specifically ebebb5f
I think it just makes sense to have a well named error class that informs the user that nothing actually went wrong, but Forest cannot continue with the data or parameters as they were provided.
My use case comes from running Forest on a server and needing to display a status page/message. If I can catch a couple Forest-specific error types I can show a custom message for each.
If something is ambiguous the developer can use exception chaining to preserve the original stack trace. (Exception chaining is just when you are inside a try-except and tack on a "from" argument like
raise MyNewError("information") from source_error
.)I can immediately think of two exception types, Data and Parameter:
Are there any other scenarios or special cases where a new reserved exception type like those two would be useful?
The text was updated successfully, but these errors were encountered: