C# – Exceptions: Compare Message Property to Know what it Means

cexceptionexception handlingmultilingual

Sometimes in an application, one might compare the Message text of an exception. For instance, if

ex.Message.Contains("String or binary data would be truncated")

then a MessageBox will be displayed for the user.

This works when testing on an English-language Windows system. However, when the program is run on a system with a different language set, then this won't work. How to ensure that only English exception messages are used?

Best Answer

As orsogufo noted, you should check the exception type or error code, and never try to parse an exception message (the message is for the user, not for the program).

In your specific example, you could do something like

try {
    ...
}
catch (SqlException ex)
{
    if (ex.Number == 8152) MessageBox.Show(ex.Message);
}

(You'll have to determine the exact error number(s) to check for.)

Related Solutions

C# – the best way to give a C# auto-property an initial value

In C# 5 and earlier, to give auto implemented properties an initial value, you have to do it in a constructor.

Since C# 6.0, you can specify initial value in-line. The syntax is:

public int X { get; set; } = x; // C# 6 or higher

DefaultValueAttribute is intended to be used by the VS designer (or any other consumer) to specify a default value, not an initial value. (Even if in designed object, initial value is the default value).

At compile time DefaultValueAttribute will not impact the generated IL and it will not be read to initialize the property to that value (see DefaultValue attribute is not working with my Auto Property).

Example of attributes that impact the IL are ThreadStaticAttribute, CallerMemberNameAttribute, ...

C# – Best Practice for Exception Handling in a Windows Forms Application

A few more bits ...

You absolutely should have a centralized exception handling policy in place. This can be as simple as wrapping Main() in a try/catch, failing fast with a graceful error message to the user. This is the "last resort" exception handler.

Preemptive checks are always correct if feasible, but not always perfect. For example, between the code where you check for a file's existence and the next line where you open it, the file could have been deleted or some other issue may impede your access. You still need try/catch/finally in that world. Use both the preemptive check and the try/catch/finally as appropriate.

Never "swallow" an exception, except in the most well-documented cases when you are absolutely, positively sure that the exception being thrown is livable. This will almost never be the case. (And if it is, make sure you're swallowing only the specific exception class -- don't ever swallow System.Exception.)

When building libraries (used by your app), do not swallow exceptions, and do not be afraid to let the exceptions bubble up. Do not re-throw unless you have something useful to add. Do not ever (in C#) do this:

throw ex;

As you will erase the call stack. If you must re-throw (which is occasionally necessary, such as when using the Exception Handling Block of Enterprise Library), use the following:

throw;

At the end of the day, the very vast majority of exceptions thrown by a running application should be exposed somewhere. They should not be exposed to end users (as they often contain proprietary or otherwise valuable data), but rather usually logged, with administrators notified of the exception. The user can be presented with a generic dialog box, maybe with a reference number, to keep things simple.

Exception handling in .NET is more art than science. Everyone will have their favorites to share here. These are just a few of the tips I've picked up using .NET since day 1, techniques which have saved my bacon on more than one occasion. Your mileage may vary.

Best Answer

Related Solutions

C# – the best way to give a C# auto-property an initial value

C# – Best Practice for Exception Handling in a Windows Forms Application

Related Topic