Closed rleonid closed 8 years ago
This is a good PR. 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.
Anyhow, I'd just merge this PR in. looks good to go.
Awesome, I'm adding an issue where we can track the discussion.
Give more power about specifying errors. I'm not ready to convert all partial functions to use an option or result type (not certain if we'll go that route), but wanted more capabilities with reporting errors. @struktured or @ihodes any opinions?