error detection

[cj]

I'm working on error handling in my program and need some input.

Dim errorsFound As Boolean = False
Dim respstr As String
Try
respstr = proxy.validate(soapmesg)
Catch ex As Exception
errorLabel.Text = ex.Message
errorsFound = True
End Try
If Not errorsFound .....

I'd rather not use boolean errorsFound. What I don't know is if an
exception occured in respstr=proxy.validate(soapmesg) can I count on
respstr being empty? If so I'll just say If not respstr = ""

 

[Chris]

I'm working on error handling in my program and need some input.

Dim errorsFound As Boolean = False
Dim respstr As String
Try
respstr = proxy.validate(soapmesg)
Catch ex As Exception
errorLabel.Text = ex.Message
errorsFound = True
End Try
If Not errorsFound .....

I'd rather not use boolean errorsFound. What I don't know is if an
exception occured in respstr=proxy.validate(soapmesg) can I count on
respstr being empty? If so I'll just say If not respstr = ""

Unless you wrote or have documenation to what returns during an error
you should not count on respstr being anything. I would reset it any
time there is an error.

Try
respstr = proxy.validate(soapmesg)
Catch ex As Exception
errorLabel.Text = ex.Message
respstr = string.empty
End Try

Another thought would be to leave the funtion if there is an error.

 

[Leon Mayne]

Unless you wrote or have documenation to what returns during an error
you should not count on respstr being anything. I would reset it any
time there is an error.

Try
respstr = proxy.validate(soapmesg)
Catch ex As Exception
errorLabel.Text = ex.Message
respstr = string.empty
End Try

Or initialize respstr outside of the try block:

respstr = string.empty
Try
respstr = proxy.validate(soapmesg)
Catch ex As Exception
errorLabel.Text = ex.Message
End Try

You could then use it (and therefore test if it is empty) outside of the try
block.

 

[cj]

Oh Oh, in my haste to make an example I forgot to say Dim respstr As
String = ""

Sorry

The point to the question is is could respstr=proxy.validate(soapmesg)
set respstr to something if it generates an exception?

You're indicating it would not. I tend to agree. But Chris said it
might. I don't know how firm each of you are in your beliefs. Let's
see what some others have to say. And by all means feel free to reply
again yourself.

 

[cj]

Good idea. Are you sure it's necessary? Leon seems to think that if
that line throws and exception it would not have changed the value of
respstr. Take a look at my response to his message. Thanks!

 

[Guest]

Oh Oh, in my haste to make an example I forgot to say Dim respstr As
String = ""

Sorry

The point to the question is is could respstr=proxy.validate(soapmesg)
set respstr to something if it generates an exception?

You're indicating it would not. I tend to agree. But Chris said it
might. I don't know how firm each of you are in your beliefs. Let's
see what some others have to say. And by all means feel free to reply
again yourself.

I'm not sure if it will or not, but my theory is, why should I risk it?

Chris

 

[Peter Huang [MSFT]]

Hi,

If the exception occured when we call the proxy.validate(soapmesg), then
respstr will be untouched.

Also if you do not continue the process in the function, why not just
return in the catch.
If you have finally code, just put it in the Finally block.

You may try to run the code below.

Try
Throw New Exception("Test")
Catch ex As Exception
MsgBox(ex.ToString())
Return
Finally
MsgBox("Finally called")
End Try

If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[cj]

I can understand your theory but I feel there shouldn't be any guessing
here. There should be an answer. And we should be able to find it.
It's a programming language and we should be able to know what it's
going to do.

 

[cj]

I agree it shouldn't be touched. I feel a lot more confident now that
it will not be.

I feel some folks might have been confused on what I was asking. I see
two types of "errors". I never had a problem with an error being
returned by validate as it'd be returned in respstr and will be checked
for. That type of error wouldn't be an exception caught in ex. This
question was strictly for if the statement throws an exception. Suppose
the connection to the remote machine was lost and validate couldn't be
run. I expect it'd throw an exception and I was confirming respstr in
such a situation would be untouched.

 

[cj]

As per your inquiry about why I don't return.

This statement is inside a do loop. If it has an exception I want to
restart the do loop with the next iteration immediately and not run the
rest of the code in the loop--or skip the rest of the code in the loop.
If you'd seen my post on "I miss loop" from 3/14 you'll know that this
was a sticky situation. If I exit do it LEAVES the loop. I no longer
have the command to initiate an immediate jump to the next iteration.

In this section of code if an exception occurs I display it in labels on
the form in case someone is looking but there is little that can be done
about it by the program except try the next loop iteration. So in this
case I really only catch exceptions to keep them from messing up my
execution. The code following the command is looking to see what's in
respstr already. I didn't want to have to set another variable to
indicate an exception occured so respstr can't be trusted. Of coure as
has been suggested, and is a good idea I could ensure respstr is blank
in the catch. But why add an extra line. I know respstr is empty
before the command is run and I SHOULD know if throwing an exception
would put put anything in it.

 

[Leon Mayne]

Good idea. Are you sure it's necessary? Leon seems to think that if
that line throws and exception it would not have changed the value of
respstr. Take a look at my response to his message. Thanks!

Ah right, I see what you're saying now. In theory respstr should be empty if
the function call threw an exception, as there would not have been a return
value. So you should be able to rely on respstr being empty, yes.

 

[Peter Huang [MSFT]]

Hi

I think you may take a look at the code below for your reference.

I can not test based on all the possibility, but commonly if the
request.GetResponse(); throw exception, the response will be null;

static void Main(string[] args)
{

// Create a request for the URL.
WebRequest request = WebRequest.Create(
"http://localhost");
// If required by the server, set the credentials.
// request.Credentials = CredentialCache.DefaultCredentials;
WebResponse response = null;
try
{
// Get the response.
response = request.GetResponse();
// Display the status.
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
if (response != null)
{

Console.WriteLine(((HttpWebResponse)response).StatusDescription);
// Get the stream containing content returned by the
server.
Stream dataStream = response.GetResponseStream();
// Open the stream using a StreamReader for easy access.
StreamReader reader = new StreamReader(dataStream);
// Read the content.
string responseFromServer = reader.ReadToEnd();
// Display the content.
Console.WriteLine(responseFromServer);
// Clean up the streams and the response.
reader.Close();
response.Close();
}

}

Also from VB.NET 2005, we have a continue keyword, which can be used to go
the next iteration of the loop without go through the all the following
code.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[cj]

Thanks.

Ah right, I see what you're saying now. In theory respstr should be empty if
the function call threw an exception, as there would not have been a return
value. So you should be able to rely on respstr being empty, yes.

 

[cj]

Thanks