[btschaegg]

When it comes to 1.), a better way to state things is may be that you shouldn't ignore errors unless you were able to completely handle them.

Catching exceptions to throw exceptions with better messages is something I would stronly suggest, since almost no exceptions are useful without contextual information. I.e. which file was not found? The config, not the input or output. Things like this. This is especially useful in C++, where you don't get stack traces, but also in other languages you'll want to present non-technical (i.e. non-dev) users with meaningful messages. Stack traces will just frighten them off.

Your comment on sensitive information also plays into this.

I'll agree that just swallowing errors and going on is a recipe for disaster. This is something that regularly bugged me in most of the C code I've encountered so far.

[narag]

Catching exceptions to throw exceptions with better messages is something I would stronly suggest

Also not every user in the world understand English.

I catch exceptions in two levels. One is the user initiated action. I seldom see this specified, but it seems obvious to me: if the user decides to do X, either X is done or a clear and meaningful message is shown, explaining what and why could not be done.

There is another finer grained location to do what you say (collecting details), logging and then re-raising up to the other level.

Swallowing errors is evil and no, not limited to C code.

[btschaegg]

Interesting point. I have to confess that I've never seen logging done usable in a i18n sense. Of course, for UI applications, you're absolutely right.

When it comes to logging details, you have a point. But I still think a clear final error message is something to aspire to - especally if you're writing very busy and potentially multithreaded (or - even worse - async) services.

On this note, filtering logs according to thread IDs can be very helpful here. I wonder if that is also easily possible with "fibers".

> Swallowing errors is evil and no, not limited to C code.

Of course, nothing ever is - it's just where I've seen this thing the most (highly anecdotal evidence, I know :-) ). Unfortunately, the nature of many C APIs also makes it very non-obvious if you're skipping through the code, whereas an empty catch statement stands out somewhat.

[dozzie]

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

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

[pjc50]

You can sometimes get stack traces in C++, but it's platform and compiler specific. Gcc's system is pretty good.

(I have some code for WinCE that walks stack traces in conjunction with SEH so that crashes in production - segfault etc - get logged in a useful manner. It does rely on parsing and decoding instructions ...)