Michel,

The reason is that .NET is using .WriteLine to form the error message. The "dot, carriage return plus another character" that you see is a period (to end the sentence), and a NewLine (CR+LF).

You might want to stay away from using the error message text in the logic of your code. You can probably accomplish the same function by using multiple Catches, one for each derived type of Exception:

Catch e As System.Data.SqlClient.SqlException
lcError = "The Query doesn't work!"
.
.
Catch e As Exception
lcError = "Generic error"

.Net will automatically step through the Catches until it finds one that it can cast the thrown Exception to. I.e., the Catch that specifies a type that is somewhere in the derivation chain of the thrown Exception.

What makes this very useful is that the online help is fairly consistient about listing the possible exceptions that can be thrown when calling a Method of a class. What isn't so great is that all of the Exceptions are spread out in different namespaces. But this shouldn't be a problem in code because you are most likely already using the namespace to call the Method.

>I have an error handling to detect for a specific message. What I don't understand is why I have to remove the last three characters in order to have a recognition of the text I am looking for:
>
>

>      Catch loError As Exception
>         lcError = loError.Message
>         lcError = Mid(lcError, 1, lcError.Length - 3)
>         Select Case lcError
>            Case "Bad Data"
>               lcError = "You didn't encrypt the XML string with a valid key."
>         End Select
>         Return lcError
>      End Try
>

>
>It seems that a dot, a carriage return and another character are by default returned when an exception occurs. Is there a reason for that?