Exceptions for Error handling

[jacobmerson]

In some ways the code we write isn't too sensitive to this since error handling typically means just crash if you did something dumb.

Since the APIs are much cleaner if we use function returns not for error codes, I would suggest that we make use of exceptions.

@cwsmith do you have strong feelings one way or another on this?

[cwsmith]

Yeah, I don't think I've been involved with any package that 'tried' to do something knowing it may not work and attempt to recover from that failure. Along those lines, I don't have any significant experience with error handling (beyond asserts etc.) so I'm pretty open to any option that is relatively simple to work with.

Do you have a small example of the exception based failure code? I've seen libraries that suggest placing try/catch blocks at the top level if the user wants to print meaningful error messages. Is that the idea here?

The xSDK folks have a 'recommended' policy, R3, regarding error handling here that we can consider:

https://figshare.com/articles/journal_contribution/xSDK_Community_Package_Policies/4495136

I like this idea:

For example, all routines may, by default, return an error code with the option of changing it to
generate an abort on the error (for running in the debugger).