> The correct thing to do in that case is to wrap/convert those errors to errors that are appropriate to that function’s interface contract. Those, however, te

> The correct thing to do in that case is to wrap/convert those errors to errors that are appropriate to that function’s interface contract. Those, however, tend to be useless. What you end up doing is placing the real error untyped into new the exception/error and that's where the real meat is. I can create an application that could retry an operation if it sees a particular kind of network error. Does it also work for the dozens of custom errors used by the interface contract of every single method? That's impossible to even know. How do I handle dozens of different SomeModuleError types? > you often aren’t even aware what failure modes you have. Again, that is the point of encapsulation and polymorphism. Maybe the implementation doesn't even exist at compile time in the case of a plugin. I don't want to have to re-write my entire application every time some implementation detail changes anywhere. If you don't want to do that, then you're have to transform your errors/exceptions into something useless. What I want to focus on what kinds of errors I can handle and where I can handle them. That has nothing at all to do with where the errors are generated.