Exception issue

All the time, to avoid any run time error, I use the Exception handler:

as the following:

try
{
    //My code which may raise an error.
}
catch (Exception ee)
{
            string message = ee.Message;
            ShowMessage();
} 

My question is:

1. Is this considered as a good practice or bad practice? (I use the same lines all the time)

2. What about the performance issue every time declaring a string?

3. When using those lines with a m开发者_StackOverflowethod which return a value, the returning must be after the catch?

That's bad code. Actually very bad.

As all you do with the error message is to assign it to a string that you never use, you are effectively just catching the exception and ignoring it. This is pretty much the worst thing that you can do with an exception, as the program will continue on as if nothing happened, likely with unusable or corrupted data.

When catching exceptions:

• Use a more specific Exception type, for example SqlException or IOException, so that you only capture the exceptions that you intend to catch, and that you know how to handle.

• When catching an exception, either really handle it, or rethrow it so that it can be handled at a different level.

You should handle known issues first to improve performance, such as null references, empty strings, etc.

Use exceptions for exceptional cases.

Declaring the string isn't a bad thing in there, but its not doing anything other than holding another reference.

You can safely return from a try block. But as Damokles states, you should also have another return else where.

The general structure of exception handling is the following:

try
{
    //do struff here
}
catch (...)
{
    //handle exception here
}
finally
{
    //clean up here
}

There are a couple of things to note in your code that are not entirely right (they are terrible in fact :p):

1. Only catch exceptions you are ready to handle and do not handle those you are not. This means that you should only catch particular exceptions (FileNotFoundException, ArgumentOutOfRangeException, whatever) that you know can happen in exceptional cases (never use exception handling as a normal execution flow tool). Catching System.Exception is considered bad practice (unless it is for logging purposes and you throw; immeadiately afterwards) because this exception can be thrown by any darn thing, which with all probability you have not foreseen when writing your code and therefore have no clue on how to handle it correctly.

2. Depending on your situation you should consider using finally blocks in order to clean up whatever you can before exiting the method (be it because of normal execution flow, or an unhandled exception). Note that finally blocks will be (normally) always executed before exiting the method scope.

3. Do not swallow exceptions and the information they contain. You should consider logging it somewhere (myApplication.log file) and show the user a more friendly "we have aproblem" message. Otherwise the only information you will have when bugs crop up in production will be whatever you show the user. All the valuable information stored in the caught exception will be lost.

There is no need to add exception handler in all the functions. Add the exception handling at the main() which wraps all the functions. Only add exceptions handlers at place where you intend to do some specific exception handling operation to prevent the application from crash.

Return value can be added in the try block.

I assume you are doing this to IGNORE exceptions? In that case you can do it like this:

try
{
// code
}
catch {} 

This will catch all exceptions and do nothing with them(ignore).

I would however not recommend doing that, because you will now never know why some functionality in your system is not working as expected because no errors are thrown. I would then recommend at the minimum at least LOG the exception so that you can troubleshoot problems later. A better approach would be to log the exception and re-throw it and then have friendly exception handling at the UI layer.

This is considered a bad practice as you basically ignore the exception. You don't even show it to the user!

It's even double bad, because it is also a bad practice to copy-paste the same lines all over your code.

Recommended usage is to either handle the exception, or do not touch it at all. As it's rather uncommon that the code knows how to handle an exception, the common case is to not catch it at all!

Of course, way up in your main loop, you'll have a try-catch, which will log the exception and/or report the exception to the user.

With respect to your second question: Yes, a return statement can be part of the catch block. But if you don't know what to return, you should not catch the exception!

You should only catch exceptions that you are expecting and know how to handle them. by catch (Exception) you are catching all kind of exceptions in a method is not a good practice.

You can catch all exceptions to just log them or restart you application on fail..

For example

try
{
    //My code which may raise an error.
}
catch (FileNotFoundException)//you are expecting this exception
{
    //handle file not found here.
}
catch (Exception ee)
{
    string message = ee.Message;
    Log(message);
    throw;//rethrow the exception
}