Theory of catching errors (C#)

[SiD the Turtle]

Hi guys. Here's a bit of pseudo-code:

try
{
  result = ConnectToSql(query);
}
catch queryException
{
  return queryException;
}
print result; // <- This fails

As the result variable is defined within the catch block, it can't be used outside of it. I could get around this by putting all my code that uses the result data inside of the try block, but I think this isn't very elegant. How would you approach this?

 

[Kobrakai]

Declare the result variable outside the try/catch blocks?

 

[Spyhop]

Yep - declaration and assignment don't have to be done at the same time.

int i;
try
{
	i = int.Parse(someString);
}
catch (Exception)
{
	return false;
}
Console.WriteLine(i);

(Yes, I know about TryParse, etc..!)

 

[Haircut]

Hi guys. Here's a bit of pseudo-code:

try
{
  result = ConnectToSql(query);
}
catch queryException
{
  return queryException;
}
print result; // <- This fails

As the result variable is defined within the catch block, it can't be used outside of it. I could get around this by putting all my code that uses the result data inside of the try block, but I think this isn't very elegant. How would you approach this?

Hang on, do you have a method that returns an exception?
What's the point in that, surely you'd be better just throing it, or not catching it there at all and letting it propagate up?
It's only very specific cases where I can see any need to have an exception as a return parameter.

Also, in the example you've given you want to print the result after the who try/catch block, this seems to make the assumption that you want the code to print the result even if an exception occurs.
It seems likely that if you get can exception when getting the result it would be pretty nonsensical to print it, so I don't see the issue with moving the print statement inside the try block.

 

[Mr^B]

try
{
  result = ConnectToSql(query);
}
catch queryException
{
  return queryException;
}
print result; // <- This fails

This code doesn't make any sense.

What is the return type of the function?

You don't return exceptions, you either deal with them and suppress them, or you don't deal with them and either re-throw back to the calling procedure, or throw an Exception of your choice in order to provide more information back to whatever is calling it, or catch the exception, log it somewhere, then re-throw it.

Also your function is actually outputting something, you should really take that out of the function and let whatever is calling the function deal with the result.

So the code calling that function would look like this:

try
{
print YourFunction();
}
catch (Exception ex)
{
LogError(ex);
throw;
}

string YourFunction()
{
  return ConnectToSql(query);
}

The rule is: Don't catch exceptions if you aren't going to do anything about with them.

LogError is a generic logging function, which will dump the contents of the exception to a logfile/windows event handler, etc...

 

[SiD the Turtle]

Thanks guys, declaring the variable outside of the try block sounds so obvious when you think about it! In general though I suppose you have to be wary of the variable's contents if the call to SQL failed.

Regarding printing the error, this is just me writing bad pseudo-code! In the app itself the call to SQL is critical to the running of the program. So if the call fails and is caught my own logging class writes the failure reason to the console and a log file and then dies, so the last print result call will either not be executed because the call fails or it will have a value.

Thanks!