3 ms·
Regarding exception handling, letting internal exceptions define external behavior is perhaps a bad idea. The possible exception types can be wide and change ov
by tabtab 8y ago
Regarding exception handling, letting internal exceptions define external behavior is perhaps a bad idea. The possible exception types can be wide and change over time as new parts or features are added. Example:
// pseudo-code
qry = new query(sql=theSql, dbConfig=DB_FOO);
if (! qry.Execute()) {
errMsg = "Something went wrong during your query. ";
if (qry.errorExceptionName=="DB_Busy") {
errMsg += "The database appears to be busy."; // append more
}
displayAlert(errMsg);
} else {
processQuery(qry.resultRows);
}
Here any fatal errors are caught inside the query object, but details are available if and when you wish to take advantage of them outside the query object. The query object (API) user doesn't have to know all possible exceptions types in order to handle an exception properly (or at least in a good-enough way).
- jdbernard 8y agoIt also bugged me that he was upset when the behavior they were relying on was an internal detail not included in the API's contract. (Incidentally, the API itself did not change because it was something like func Read(in Reader) error, where error was a parent of all exceptions) That's not incidental. In my opinion the authors of the API were completely fine changing the internal detail of which specific exception type was thrown because their public API never made a guarantee beyond it being an instance of error.
- tabtab 8y agoFuture-friendly error-handling can indeed be tricky. I ran into this trying to make a lasting email-sending API. I was hesitant to depend on the API's specific exception types, and so considered mapping them to more general categories, yet still giving details for troubleshooting. // pseudo-code err = new Error(hasError=false); // innocent until proven guilty try { sendEmail(...); catch (e in excptn1, excptn6, excptn7) // dummy names err.hasError=true; err.recipientProblem=true; err.errorType = e; catch (e in excptn2, excptn4, excptn9) err.hasError=true; err.contentProblem=true; err.errorType = e; catch (else) err.hasError=true; err.errorType = e; } ... return(err); One could make an emumerable list of error categories, but in this case I wasn't even sure they were mutually exclusive because it still sends to the rest if one recipient is bad.
- jack9 8y ago> letting internal exceptions define external behavior is perhaps a bad idea In practice, I've preferred it for years.