Search

System.Timers.Timer swallows exceptions by Alfred Myers

Closed
as External Help for as External

14
0
Sign in
 to vote
Type: Bug
ID: 286105
Opened: 7/4/2007 11:44:42 AM
Access Restriction: Public
2
Workaround(s)
6
User(s) can reproduce this bug
Exceptions thrown inside a Timer.Elapsed event handler get swallowed.
They should:
a) allways be propagated up the stack or...
b) The Timer class could have a member indicating if exceptions during Elapsed should be propagated or not;
Details (expand)
Product Language
English

Version

.NET Framework 2.0
Operating System
Windows XP Professional
Operating System Language
English
Steps to Reproduce
using System;
using System.Timers;

namespace ForumMsdn {
class Program {
static void Main(string[] args) {
Timer timer = new Timer(1000);
timer.Elapsed += new ElapsedEventHandler(timer_Elapsed);
timer.Start();
Console.Read();
}

static void timer_Elapsed(object sender, ElapsedEventArgs e) {
Console.WriteLine("Hello world!");
throw new Exception("The method or operation is not implemented.");
Console.WriteLine("I hope that some day I'll be executed");
}
}
}
Actual Results
The second Console.WriteLine obviously never gets executed, but we don't get an indication that there has been an error.
Expected Results
The exception should be propagated up the stack
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
0 attachments
Sign in to post a comment.
Posted by Dmitry R. _ on 3/19/2011 at 7:24 PM
and it's not fixed in final .net 4.
three years of fixing. nice
Posted by thijsk on 2/23/2010 at 11:09 AM
Also not fixed in .NET 4 RC
Posted by Bruno Martinez on 10/8/2008 at 10:12 AM
This bug is still there in .Net 3.5 SP1. I've been bumping into this situation lately. Events that supposedly fire on the thread pool don't respect the swallow nothing semantics.
Posted by Microsoft on 7/12/2007 at 11:03 AM
Alfred,

We are aware of this issue and will be fixing it in a later version of the Framework.

Thank you for bringing this to our attention.


Inbar Gazit
Microsoft Corporation
Posted by Alfred Myers on 7/11/2007 at 4:14 PM
Just to add some information here.
What I'm suggesting here is that you have a property a la Control.CheckForIllegalCrossThreadCalls (http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.checkforillegalcrossthreadcalls.aspx) wich would allow us to set if we want the exception be propagated up the stack or not.
The default value of the property would correspond to the current behavior.
Posted by Microsoft on 7/4/2007 at 6:41 PM
Thanks for your feedback. We have reproduced this bug on Visual Studio Codename Orcas Beta1, and we are sending this bug to the appropriate group within the VisualStudio Product Team for triage and resolution.

Thank you,
Visual Studio Product Team.
Posted by Microsoft on 7/4/2007 at 5:43 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com).

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by Alfred Myers on 7/4/2007 at 11:49 AM
Add exception handlers to all Timer.Elapsed event handlers.
The exception handler could log the exception somewhere.
Although the exception would be logged, this is not as visible as the exception being propagated up the stack evenutally blowing the application - luckly during the stabilization phase.
Posted by Alfred Myers on 7/23/2007 at 7:35 AM
Use System.Threading.Timer instead. The API is somewhat different, but changing System.Timers.Timer for an System.Threading.Timer isn't such a big task.
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement