tags:

views:

262

answers:

4

I need a little advice.

I've got windows service that runs at night. In my development environment, it runs without exception, but when I running it "installed on other machines", when I come in the morning, I'm welcomed with a System.Overflow exception that says that I've set an int32 to a value that is too large or small.

I've carefully combed the service's c# code, and I have try/catch statements around everything, that should catch any error and write it to a log without completely stopping my service with this overflow exception. But still, it occurs and stops the service.

I'd appreciate any conceptual advice on how to pin point what's causing an error such as this.

+1  A: 
  • You must have missed an instance of try/catch or you have an error in your error handler or it would be handled.
  • In windows you can setup your service to restart if it ends unexpected manner.
rerun
You were right, I missed a try/catch.
LonnieBest
+2  A: 

First, let me tell you that overflow/underflow can be disabled, by opening project properties, selecting "Build" (from the left menu), and then "Advanced...".

By the way, I do it all the time, because it adds overhead, which I don't want in my scientific applications. Manually, then I control things.

But that does not solve the issues... It just hides the "problem", if it is a problem.

If you only care to check about a zero/non zero condition, somewhere in your code, disabling overflow at project settings solves the problem, because even when an overflow occurs you get a nonzero value, and your service continues without problems.

ileon
Do you disable this by default, or only in your release builds? I hope the latter so that you remove any potential errors in your code, or that you have unit tests to cover this :) And it's better to disable it where you know it's ok with the unchecked keyword imo.
Mikael Svenson
@Mikael Svenson: You are right, in release build I disable arithmetic overflows/underflows, due to the involved overhead.
ileon
Never knew that was there, but it seems to be disabled by default. Turning it on doesn't seem to make a discernible performance difference in my raytracer, perhaps the JIT just doesn't think it's necessary.
JulianR
@JulianR: for GUI code or code that does not perform intensive calculations (like mathematical computations) you will not notice any difference. But, try to play with this option on code that solves a system of 200000 simultaneous equations, and you'll see!
ileon
I'd put a realtime raytracer in the "computationally intensive" category. Still doesn't make any difference. Not saying the checks don't have a performance impact, just saying that those checks *don't seem to be actually there at all*.
JulianR
+1  A: 

The problem with adding try/catch blocks throughout your code is it's easy to miss a place and hence not log the exception. A much more robust approach is to use the value AppDomain.UnhandledException. This will fire for any exception which is not handled within the current AppDomain. You can hook into this to write to your log file and hopefully get a better idea at where the error is coming form

AppDomain.CurrentDomain.UnhandledException += OnUnhandledException;

...

void OnUnhandledException(object sender, UnhandledExceptionEventArgs e) {
 // Log the exception here
}
JaredPar
+1  A: 

Also, for WinForms applications:

http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx

And WPF:

http://msdn.microsoft.com/en-us/library/system.windows.application.dispatcherunhandledexception.aspx

To get visibility of exceptions on UI threads, since they're not forwarded to AppDomain.CurrentDomain.UnhandledException.

Leon Breedt