Exception problems between languages

[Donald Adams]

I have a new problem with Exceptions: I need to manage the exception but I
don't have an error code to compare with, just messages. I can check a
message to see if it has "timeout" then instruct my code to try again later,
however, if the message is "not found" then I want to rethrow the exception
or log it. This can work fine, but the real problem comes when I install
this on a system that produces exception strings in another language like
Chinese, then I can no longer catch and manage using the message string.
Anyone, know how to handle this?

Thanks in advance,
Donald Adams

[Dave]

You should absolutely, positively, *not* use the error message as a means of
determining what type of exception has occurred. These messages can easily
change, either between revisions, between locales, when new layers are added
between your code and the underlying source of the exception, or when a
subsystem component gets changed that performs the same function but uses a
slightly different error message. There is no standard that applies to error
messages, certainly not one that is enforced by the runtime, thus there is
no way you can be sure that your app wont break. This sort of fragility
should be avoided at all costs.

Instead, you should use the exception type itself to determine how to handle
the error. You should catch the most specific exception type and handle the
error appropriately. For example, FileNotFoundException is thrown when an
attempt to access a file on disk fails. Catch this and deal with it rather
then look at the message to determine if the access failed.

If the exception is thrown by a COM object or an external Win32 method then
this becomes harder because you will only get a single exception type
(either COMException or SEHException). You can use the ErrorCode property to
retrieve the specific HRESULT that was returned by the faulting method.

If there really is no programmatic means of determining the cause of the
exception other then the message then I would approach the supplier of the
component and ask them to supply specific exception types (or HRESULTS for
Win32 methods) for each error type - good component practice should dictate
this anyway. If this cannot be done then you are on your own.

Dave L
"Donald Adams" <BD******@hotmail.com> wrote in message
news:OF*************@tk2msftngp13.phx.gbl...

I have a new problem with Exceptions: I need to manage the exception but I
don't have an error code to compare with, just messages. I can check a
message to see if it has "timeout" then instruct my code to try again later, however, if the message is "not found" then I want to rethrow the exception or log it. This can work fine, but the real problem comes when I install
this on a system that produces exception strings in another language like
Chinese, then I can no longer catch and manage using the message string.
Anyone, know how to handle this?

Thanks in advance,
Donald Adams

[Dave]

You should absolutely, positively, *not* use the error message as a means of
determining what type of exception has occurred. These messages can easily
change, either between revisions, between locales, when new layers are added
between your code and the underlying source of the exception, or when a
subsystem component gets changed that performs the same function but uses a
slightly different error message. There is no standard that applies to error
messages, certainly not one that is enforced by the runtime, thus there is
no way you can be sure that your app wont break. This sort of fragility
should be avoided at all costs.

Instead, you should use the exception type itself to determine how to handle
the error. You should catch the most specific exception type and handle the
error appropriately. For example, FileNotFoundException is thrown when an
attempt to access a file on disk fails. Catch this and deal with it rather
then look at the message to determine if the access failed.

If the exception is thrown by a COM object or an external Win32 method then
this becomes harder because you will only get a single exception type
(either COMException or SEHException). You can use the ErrorCode property to
retrieve the specific HRESULT that was returned by the faulting method.

If there really is no programmatic means of determining the cause of the
exception other then the message then I would approach the supplier of the
component and ask them to supply specific exception types (or HRESULTS for
Win32 methods) for each error type - good component practice should dictate
this anyway. If this cannot be done then you are on your own.

Dave L
"Donald Adams" <BD******@hotmail.com> wrote in message
news:OF*************@tk2msftngp13.phx.gbl...

I have a new problem with Exceptions: I need to manage the exception but I
don't have an error code to compare with, just messages. I can check a
message to see if it has "timeout" then instruct my code to try again later, however, if the message is "not found" then I want to rethrow the exception or log it. This can work fine, but the real problem comes when I install
this on a system that produces exception strings in another language like
Chinese, then I can no longer catch and manage using the message string.
Anyone, know how to handle this?

Thanks in advance,
Donald Adams