When parsing user input, it is generally recommended to not to throw and catch exceptions but rather to use validation methods. In the .NET BCL, this would be the difference between, for example,
int.Parse (throws an exception on invalid data) and
false on invalid data).
I am designing my own
Foo.TryParse(string s, out Foo result)
method and I'm unsure about the return value. I could use
bool like .NET's own
TryParse method, but that would give no indication about the type of error, about the exact reason why
s could not be parsed into a
Foo. (For example,
s could have unmatched parenthesis, or the wrong number of characters, or a
Bar without a corresponding
As a user of APIs, I strongly dislike methods which just return a success/failure Boolean without telling me why the operation failed. This makes debugging a guessing game, and I don't want to impose that on my library's clients either.
I can think of a lot of workarounds to this issue (return status codes, return an error string, add an error string as an out parameter), but they all have their respective downsides, and I also want to stay consistent with the conventions of the .NET Framework.
Thus, my question is as follows:
Are there methods in the .NET Framework which (a) parse input without throwing exceptions and (b) still return more detailed error information than a simple true/false Boolean?