不抛出异常（在Win7中？）

Question

I have application reads in data from text file. Recently I realized that I should make a data checker for the data in the text file, to see if I can display/handle it correctly.

Basically at the moment all the checker does is see if data is in the correct format, ie double is a double, int is int, etc... And if it isn't I'm throwing an exception.

Like so:

private static string CheckDouble(string doublevar)
        {
            double tryParseDoubleResult;
            var tryParseDouble = double.TryParse(doublevar, out tryParseDoubleResult);

            if (tryParseDouble)
            {
                return doublevar;
            }

            throw new Exception("Invalid data found. Cannot open.");
        }

Which would be great. Except for the following:

• I built this in Win 7 Environment in VS 2008.
• I've tested in Win7/ XP
• When running in Win7 - the exception does not throw. I can even see that it should have, as I display the data it loads into a listbox in the app, but after loading the list is blank. If I step through the code line by line to the item where there is bad data, I can see the exception throw. But not in Debug if not debugging line by line, and not in Release either.
• In XP the exception throws as expected.

This is obviously a problem having the application run in a state where there is problem with the data but no indication to user and it should not have let the user get this far IF there was a problem with the data.

Why isn't the exception throwing in Win7?

---

edit:

I think maybe the exception is being swallowed as I only see it thrown when stepping through line by line. What is the best way to check if it is being swallowed? Just follow my apps execution and look for a Try block? (It still doesn't exactly make sense when it throws properly in XP already, however...)

As a bit of extra, I have a start up window with 3 buttons. One is Open button. From here I open the data file to process.

var w = new Window1();
w.Show();

//At this point, FormLoad of all tabitems inside window1 execute, where the exception SHOULD throw. And in fact when it happens, nothing is thrown but the execution jumps from the line where the exception should throw to the line below Close(); and the next window loads but one screen out of three is empty because of the exception thrown because of the data.

Close();

---

edit1:

The class where the exception is thrown is Singleton, I don't know if this has anything to do with the problem...

edit2:

After several days further investigation, I'm still at a lost to why this is happening. Addressing the questions: yes I know I should make my own custom exception class. But this doesn't change what is happening here. I cannot find a try catch higher up the stack. I have an exception handler where if an exception is thrown in the application, it Environment.Exit(1); then logs the exception to text file. I have taken the exception handler out completely and yet still see the same behaviour.

It is not due to regional settings problem...

And anyway, all aside, this still does not explain why the exception is thrown as intended in XP (and the app crashes and logs exception to file) whereas in Win7 - the exception is ignored and execution continues.

Answer 1

First, you really should be throwing your own exceptions. System.Exception is the top-level exception from which all exceptions inherit. Consider creating a DataFormatException, for example - and throwing that.

Next, it sounds like you are likely catching System.Exception someone lower in the stack that is swallowing this exception. Again, it would be ideal if you only catch System.Exception at the lowest point in the stack for that thread, and use that as a catch-all for the whole application. In other places in your code, you should catch the exceptions that expect to happen. For example, the caller of your method should only trying to catch DataFormatException and ArgumentException (which you should throw if "doublevar" is null or empty). For example:

/// <summary>
/// Checks to see if the specified value is a double.
/// </summary>
/// <param name="valueToCheck">The value to check.</param>
/// <exception cref="ArgumentException">If <paramref name="valueToCheck"/>
/// is null or empty.</exception>
/// <exception cref="DataFormatException">If <paramref name="valueToCheck"/>
/// could not be parsed as a valid double.</exception>
private static double CheckDouble(string valueToCheck)
{
    if (string.IsNullOrEmpty(valueToCheck))
        throw new ArgumentException("Argument 'valueToCheck' cannot be null or empty.", "valueToCheck");

    double result;

    if (double.TryParse(valueToCheck, out result))
    {
        return result;
    }

    throw new DataFormatException("Value '" + valueToCheck + "' could not be parsed as a double.");
}

Hope that helps...

Answer 2

I am assuming you are using tryparse here and rethrowing the exception just to demonstrate that try parse isn't working as expected... Why not try adding a Debug.Print inside you're if statement to see what you are getting.

Also, make sure this code isn't being called from another function that is wrapping this code with a try/catch block that is swallowing the exception

Answer 3

When you're stepping through in debug mode, you can see the exception getting thrown, right? What happens after that? That is, after the throw new Exception() line, where do you end up when you press F10? That's where the exception is being swallowed.

If you end up in framework code somewhere, it means you need to manually add a try...catch yourself in the code that processes the file:

void Form_Load(object sender, EventArgs e)
{
    try
    {
        ParseFile();
    }
    catch(Exception ex)
    {
        MessageBox.Show("The file was not valid: " + ex.Message);
    }
}

Answer 4

Most likely your computers differ in their regional settings. For example thousand/decimal separators differ between countries, eg "1,000.00" vs "1.000,00", DateTime formats differ, etc. Try using Parse/TryParse/ToString overloads which specify CultureInfo explicitly and avoid defaulting to computer's settings, perhaps by using CultureInfo.InvariantCulture .