Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with errors #154

Open
rleonid opened this issue Mar 2, 2016 · 0 comments
Open

Dealing with errors #154

rleonid opened this issue Mar 2, 2016 · 0 comments
Labels

Comments

@rleonid
Copy link
Owner

rleonid commented Mar 2, 2016

A place to discuss the usage of a result type, option type or exceptions in oml.
From #153 @struktured wrote

I think adopting a result or or_error type is interesting if done appropriately. For the most part I would definitely go beyond optional if you are going to bother at all encoding the errors in return types.

The strictness and explicitness of the error handling should correspond to how much we would expect a particular function to "misbehave", and thus will probably need to vary by module and/or function signature. In general it's probably best to prefer implicit error handling so mathematicians can focus on the meat of their computations, but I'm open to counter arguments.

For instance, it would be nice to know when training a model that some particular hyperparameter was invalid or led to non-convergence- we can then condition on it that information and try different inputs. More generally, you could imagine any function reporting what input parameter or derived value (with semantically meaningful name) broke the results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant