I think it's fine to use exceptions as error handling if the stack can safely be destroyed with that exception. As the article states, they provide a lot of inf

I think it's fine to use exceptions as error handling if the stack can safely be destroyed with that exception. As the article states, they provide a lot of information to help debugging and are resilient to refactoring. An example of safe stack destruction is a web service call that cannot complete because of the error. You're going to return an error response regardless. I don't think exceptions should be used if they are caught and then retried or transformed. I don't think exceptions should be used in library code, except of course for unanticipated behavior such as hardware or network problems. In these cases it's better to use a result object, which better forces the library consumer to inspect what is being returned, rather than pass on what is returned and (maybe?) handle exceptions on errors. Ideally the library catches unanticipated errors and never throws, but those are edge cases that are probably not worth the investment by the library maintainer to handle. Development effort across the ecosystem is probably minimized when library consumers handle exceptional situations themselves, which they may have more insight into if their own infrastructure is causing the exception.