It 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.
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.
(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.