undefined | Better HN

0 pointsdozzie9y ago0 comments

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

0 comments

btschaegg9y ago

If 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.configuratio...

j / k navigate · click thread line to collapse

0 pointsdozzie9y ago0 comments

> Catching exceptions to throw exceptions with better messages is something I would stronly suggest, since almost no exceptions are useful without contextual information.

0 comments

btschaegg9y ago

[1]: https://msdn.microsoft.com/de-de/library/system.configuratio...

j / k navigate · click thread line to collapse