Why not log all exceptions in SharpDevelop?

[zhujiem]

Dear SharpDevelop team,

I'm working on logging practices in software development. Logging is a common programming practice used to assist in tracking down bugs or unexpected behaviors. Currently, I have used SharpDevelop as a target project and studied the logging statistics from its source code.

In my study in SharpDevelop , there are 1,346 catch-blocks in total and only 252 (19%) of them are logged. A significant portion of catch-blocks are actually not logged.

Exceptions are widely used for error handling in C#. Exception logging is important, because these logs can provide strong indicators of the error sites and are helpful at determining what went wrong. Some studies point out that logging all exceptions can greatly reduce the diagnosis time of post-release failures. Also, logging all exceptions will not incur much runtime overhead, because compared to other statements, the execution of exception-handling code is much rarer during normal runs.

So I have the question:

1. Why NOT log all exceptions in SharpDevelop? What problems may be caused if logging all exceptions?
2. What are the concerns to decide whether to log an exception during development?
3. Do you think logging all exceptions is a better practice or not logging all exceptions a better practice?

Thank you very much! Your replies are highly appreciated and can broaden my understanding on exception logging.

[aleksoft]

Logging all exceptions can quickly overflow your exception logging medium. Many exceptions are well expected and the exception handler should deal with them appropriately, quite often do nothing at all.
Consider for example "Suggest as you type" feature: Until a typed-in string actually contains something usable, you may get an exception on every key press, not something you really want to log.

[medmondson]

I'd have to agree with @jimzhu. Exceptions exist for a situations that are exceptional which by definition is not something you expect to happen. Exceptions are very resource intensive and certainly shouldn't form part of the normal flow of the application. Directly from MSDN:

Throwing or handling an exception consumes a significant amount of system resources and execution time. Throw exceptions only to handle truly extraordinary conditions, not to handle predictable events or flow control.

In disagreement with @aleksoft the "Suggest as you type" feature should not be casually throwing such exceptions, which is an abuse of the .net exception pattern IMO.

[dgrunwald]

SharpDevelop is an interactive GUI application.
The 'Log' in SharpDevelop is pretty much only for debug purposes. In 'Production' (=on end-user machines), the log is not saved anywhere by default.
Instead, the usual way to handle unexpected exceptions is to show them to the user (in a regular message box if the error is likely to be caused by the user configuration; in our 'unhandled exception' dialog box otherwise). I'm not sure if these MessageService calls were included in the statistic, since the Log API is not directly used in the catch block (but the MessageService implementation is logging the message in addition to displaying it).

Then there's also exceptions that we intentionally ignore without logging because we know their meaning -- e.g. OperationCanceledException. And exceptions that are rethrown, which only are logged/displayed/ignored in the final catch handler, not at every point where they are caught.

@medmondson: 'Exceptions are very resource intensive' is relative. You can throw thousands of exceptions per second and be fine. They're much more expensive than method calls (where you can do millions of calls and be fine), but an exception on every keypress is not going to cause noticeable CPU use. And it may be unavoidable if using an existing parser that throws exceptions on invalid/incomplete code (e.g. System.Xml.XmlTextReader for XML editing)