Future-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

Future-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.