3 ms·
> Catching exceptions to throw exceptions with better messages is something I would stronly suggest, since almost no exceptions are useful without contextual in
by dozzie 10y ago
> Catching exceptions to throw exceptions with better messages is something I would stronly suggest, since almost no exceptions are useful without contextual information.
Much more important is to wrap these exceptions generated in internal code
in custom types. List of raised exceptions is a part of code's interface, and
one shouldn't generally expose this kind of internal details as public API.
- btschaegg 10y agoIf you're wrapping third party code that uses custom exception types, absolutely. However, regarding custom types, I found that you can get astonishingly far with most standard error types defined by many languages. So, if the internal code already uses those, I wouldn't see them as much of a problem - a FileNotFoundException essentially may as well stay one. Of course, default exception types won't work if you have to convey more contextual information that is missing in the according interface. Also, using the same default exception type for different underlying errors can be problematic (an example for this would be C#'s AppSettingsReader.GetValue()[1] - it makes it impossible to distinguish between a parsing error or a missing key via the API). [1]: https://msdn.microsoft.com/de-de/library/system.configuration.appsettingsreader.getvalue(v=vs.110).aspx https://msdn.microsoft.com/de-de/library/system.configuratio...