CODEWITHSUNDEEP
c#exceptionwindows-mobilecompact-framework
Barry
Barry

Reputation: 1

Unexpected value in Exception object in catch block (c# compact framework)

I maintain a c# compact framework application and have had 2 cases in 2 days where the a caught exception had a unexpected string in the Message. Both times due to a different exception type being thrown. In the following code the socket exception is caught, but the message shown relates to something else.

 //method1
 try
 {
     soc.Connect(new IPEndPoint(IPAddress.Parse(_serverAddress), _serverPort));

 }
 catch (Exception ex)
 {
     MessageBox.Show(ex.Message)
 }



 //method2
 try
 {
     m_socServer.Connect(new IPEndPoint(IPAddress.Parse(_serverAddress), _serverPort));

 }
 catch (SocketException sex)
 {
     MessageBox.Show(sex.Message)
 }

In 'method1' the exception is thrown upon fail to connect, the catch block entered, but the message box shown an exception I know is from outside of this try block. In 'method2' the exception is caught and the message is correct. These two try catch blocks are the only thing changed in the code.

I have yet to reproduce this in a small test program, but the program I maintain has this behaviour.

Where and why does 'method1' not get the unexpected value?

Upvotes: 0

Views: 1155

Answers (3)

pauloya
pauloya

Reputation: 2563

When you handle exceptions you can think of who needs to be notified of the error: the user? or the admin/developer?
You can define that a SocketException contains a message that the user needs to be notified of, and every other exception should be saved for developers or administrators to see. For example you can write the full exception to a file, or event you can have a special MessageBox. "Unexpected Error, please notify the administrator: " + ex.ToString().
Make sure you write the whole ex.ToString() because it includes the stacktrace and all InnerException's.

The best practice is to keep the catch(Exception ex) on the outer level of your application so you handle all unexpected exception in one place.

Upvotes: 1

Reed Copsey
Reed Copsey

Reputation: 564831

You are probably mistaken - in these 2 cases, some other exception (the one you're receiving) is being thrown instead of a SocketException.

If you're only expecting SocketException to be thrown, you should only provide a handler for that case. Other exceptions, in this situation, are probably truly exceptional - meaning that you aren't going to be able to correctly recover.

In that case, it's usually better to not handle the exception, and let it bubble up. If you feel that this is incorrect, put in the SocketException handler AND a generic exception handler, and make sure to check your stack traces (and potentially InnerException properties) in the exceptions:

try
{
    //throw SocketException
}
catch (SocketException sockEx)
{
    MessageBox.Show(sockEx.Message)
}
catch (Exception ex)
{
    MessageBox.Show(ex.Message)
}

Upvotes: 2

Justin Niessner
Justin Niessner

Reputation: 245479

The statement you have above will catch ALL Exceptions, not just a specific type of exception.

If you want to handle specific exception types, you need to have code similar to this:

try
{
    // Do some work.
}
catch(SocketException ex)
{
    // Handle a known SocketException
}
catch(NullReferenceException ex)
{
    // Handle a known NullReferenceException
}
catch(OtherSpecificException ex)
{
    // You get the idea
}
catch(Exception ex)
{
    // This will be everything else you haven't explicitly caught.
    // It will also give you the most generic details about the Exception.
}

Upvotes: 1

Related Questions