What is the rationale behind the (probably undocumented) cases of .NET suppressing exceptions?

Question

I am trying to grasp the the .NET criterion where, when .NET exceptions are suppressed, swallowed or passed unnoticed in order to detect/suspect/prevent/be on alert about such incidents.

The MSDN online article "Timer Class" on .NET Framework 4.5 states:

In the .NET Framework version 2.0 and earlier, the Timer component catches and suppresses all exceptions thrown by event handlers for the Elapsed event. This behavior is subject to change in future releases of the .NET Framework

Hmmm, is the .NET 4.5 an already future release in relation to .NET 2.0?
Though this is a rhetorical question and I do not care much about a specific case which was mentioned in docs.

What I do care and want to understand is:
What are criterion, principles and rationale according to which the .NET exceptions are being suppressed?

Update (in response to Eugen Rieck's answer:

So the question is: Which thread should be subject to am exception thrown on a timer tick?

Citing MSDN article "Exception Handling (Task Parallel Library)" :

If you do not wait on a task that propagates an exception, or access its Exception property, the exception is escalated according to the .NET exception policy when the task is garbage-collected.

(Funny ".NET exception policy" which I could not find anywhere ...)

Well, I am interested in WPF app, which, as I understand, is STA and has one main parent thread.
My wish is that it crashes if any exception was unhandled.

Update2 (in response to Matt Smith' comment):

Yes, I know. Citing <ThrowUnobservedTaskExceptions> Element:

If an exception that is associated with a Task has not been observed, there is no Wait operation, the parent is not attached, and the TaskException property was not read the task exception is considered to be unobserved.

In the .NET Framework 4, by default, if a Task that has an unobserved exception is garbage collected, the finalizer throws an exception and terminates the process. The termination of the process is determined by the timing of garbage collection and finalization.

To make it easier for developers to write asynchronous code based on tasks, the .NET Framework 4.5 changes this default behavior for unobserved exceptions. Unobserved exceptions still cause the UnobservedTaskException event to be raised, but by default, the process does not terminate. Instead, the exception is ignored after the event is raised, regardless of whether an event handler observes the exception.

In the .NET Framework 4.5, you can use the element in an application configuration file to enable the .NET Framework 4 behavior of throwing an exception.

I just skipped to go further on it to avoid the bloafing of question and getting the reference to explanation by Stephen Toub's "Task Exception Handling in .NET 4.5"

The question is after all (really wanted to start with this question) to make sure for me :

• Is there a common ".NET exception policy" mentioned in MSDN "Exception Handling (Task Parallel Library)", to have it clearly formulated in one place ?
• is it .NET version-dependent or independent?
• Where is it formulated?

Answer 1

Here's the link to the policy (it was changed in .net 2.0) and has remained the same since then: http://msdn.microsoft.com/en-us/library/ms228965.aspx

Answer 2

Most possibly this is simply an implementation issue:

• Timer ticks run on a threadpool thread
• The timer itself doesn't belong to a thread
• The thread, that created the timer, might no longer run (or exist)

So the question is: Which thread should be subject to am exception thrown on a timer tick? There is no easy answer to that, so simply suppressing the exception (i.e. running every tick with an implied try ... catch around it) is a way to sidestep this question.