We Keep Coding

How to avoid catching generic exceptions

In my processing I would like to log any error along with the user and code details and proceed on with my work.
I am currently using a try catch block which includes a generic catch, but is catching a generic exception is a bad thing? Such as the exception could be a stackoverflowexception or outofmemoryexception and need to be handled differently.. .
But I am not sure how to avoid catching these fatal exceptions. I am looking for suggestions.
Why I want to catch all exceptions
Because I don't want a failure in one form's processing to affect the others in the loop.
Why I am catching specific exceptions:
I understand I can look for stackoverflowexception, outofmemoryexception etc... but my point is, there could be many of them...looking for each and every would make my code lengthy. I am not sure if that is the best process.

But I am not sure how to avoid catching these fatal exceptions
Well, 2 things.
First, you can always rethrow them, for example, after logging.
Second, you can catch every exception you want and if you do not catch System.Exception then all you do not catch will bubble up - that is C# 101 for beginners, so if you have a problem with that, back to reading the documentation about exceptions in general.

Exceptions cascade down. If you want to handle certain exceptions differently, implement a different catch block.
try
{
ThisMethodMayThrowException();
}
catch(StackOverflowException ex)
{
//handle a StackOverFlowException
}
catch(OutOfMemoryException ex)
{
//handle a OutOfMemoryException
}
catch(Exception ex)
{
//handle all other types.
}
In general though, you should only plan to handle expected exceptions. For example, if you're writing to a file that you expect to exist, you might anticipate a FileNotFoundException. If you tried to handle every possible exception, your code would become quite long and unwieldy, to little benefit.
Microsoft provides excellent info on exception handling.

Reverse your thinking... because the advice catching generic exception is being misinterpreted.
Handle all exceptions which are known explicitly (do the log and continue processing), but always have a generic catch all exception handler to stop all processing and handle that unknown.
In your example an overflow exception could comprise data or let malicious actors take over the system in unexpected ways; hence continuing on, should not be done.

If you know all the exceptions you want to catch, you write a catch block for each specifically:
try
{
}
catch (IOException)
{
}
catch (InvalidCastException)
{
}
...
Then all the ones you don't want to catch (and thus allow to potentially take down your program) will keep bubbling up.

I am currently using a try catch block which includes a generic catch,
but I have heard from many people that catching generic exception is a
bad thing(as the exception could be a stackoverflowexception or
outofmemoryexception).
You should know which Exception types your method calls might throw.
It could be discovered either at the Method documentation, example:
/// <exception cref="DivideByZeroException">Why it's thrown.</exception>
public void MethodThatMightThrowDivideByZeroException(){...}
or by looking at the Method code, example:
throw new DivideByZeroException();
That way, you would be able to catch it easily:
try
{
ThisMethodMayThrowException();
}
catch(DivideByZeroException ex)
{
//handle a DivideByZeroException
}

C# Error handling catch blocks

Why is it adviced most of the time that we should not trap errors like "Exception" but trap errors that we expect as developers.
Is there a performance hit in trapping generic errors or is it recommended from a best practice point of view?
try
{
// Do something
}
catch(Exception e)
{
//Log error
}

The best practice is to catch specific exception first and then move on to more generic ones.
Exception Handling (C# Programming Guide)
Multiple catch blocks with different exception filters can be chained
together. The catch blocks are evaluated from top to bottom in your
code, but only one catch block is executed for each exception that is
thrown. The first catch block that specifies the exact type or a base
class of the thrown exception is executed. If no catch block specifies
a matching exception filter, a catch block that does not have a filter
is selected, if one is present in the statement. It is important to
position catch blocks with the most specific (that is, the most
derived) exception types first.
For your question:
Why is it adviced most of the time that we should not trap errors like
"Exception" but trap errors that we expect as developers.
An example would be to catch NullReferenceException. Its never a better practice to catch NullReferenceException, instead one should always check for object being null before using its instance members. For example in case of string.
string str = null;
try
{
Console.WriteLine(str.Length)
}
catch(NullReferenceException ne)
{
//exception handling.
}
instead a check should be in place for checking against null.
if(str != null)
Console.WriteLine(str.Length);
EDIT:
I think I got the question wrong, If you are asking which exception should be caught and which shouldn't then IMO, those exceptions which can be dealt with should be caught and rest should be left in the library so they can bubble up to upper layer where appropriate handling would be done. An example would be Violation of Primary key constraint. If the application is taking input(including primary key) from the user and that date is being inserted into the database, then that exception can be caught and a message can be shown to user "Record already exists" and then let the user enter some different value.
But if the exception is related to the foreign key constraint (e.g. Some value from the dropdown list is considered invalid foreign key) then that exception should bubble up and a generic exception handler should log it in appropriate place.
For example in ASP.Net applications, these exception can be logged in Application_Error event and a general error page can be shown to the user.
EDIT 2:
For the OP's comment:
if at a low level if there would be a performance degeradation in
catching a generic error inspite of knowing if the error is
sqlexception
Even if there is going to be any performance difference it should be negligible. But Catch the specific exception, if you know that the exception is going to be SqlException then catch that.

You should only catch exceptions what you can handle. Exception is too generic so most of the time you cannot say you can handle that. It is a little funny but you should only catch exception that you except :)
There are situation when you need to catch Exception but rare and you should avoid it most of the time. Usually it indicates some design problem.

Check Eric Lippert's blog (Vexing exceptions) about best way to handle exceptions.
• Don’t catch fatal exceptions; nothing you can do about them anyway, and trying to generally makes it worse.
• Fix your code so that it never triggers a boneheaded exception – an "index out of range" exception should never happen in production code.
• Avoid vexing exceptions whenever possible by calling the “Try” versions of those vexing methods that throw in non-exceptional circumstances. If you cannot avoid calling a vexing method, catch its vexing exceptions.
• Always handle exceptions that indicate unexpected exogenous conditions; generally it is not worthwhile or practical to anticipate every possible failure. Just try the operation and be prepared to handle the exception.

Using exception handling more often than required is infact a lazy way of programming more than anything. Say you have a DataTable and you want to access the first row.
public DataRow AccessFirstRow(DataTable dt)
{
try
{
return dt.Rows[0];
}
catch (Exception e)
{
//There isn't a first row or dt is null
}
}
Instead of
public DataRow AccessFirstRow(DataTable dt)
{
if(dt != null)
if(dt.Rows.Count > 0)
return dt.Rows[0];
//If we can't access dt, then don't
return null;
}
My rule of thumb is:
Exceptions should only be used in EXCEPTION-al circumstances.
If you do decide to handle them though, as mentioned handle specific exceptions you know you might encounter instead of generic exceptions.

It's a best practice thing. The idea is that you should quickly handle the known exceptions explicitly while having more general ones higher up in the program as unexpected exceptions are likely caused by some more major/fundamental error.

Catch those exceptions which you intend to handle. You will usually want to handle particular exception in such context (method) where you have enough information for dealing with error reported (e.g. access to objects used for clean-up).
If code within try block throws different types of exceptions, you might want to handle some exceptions within the same method and re-throw others in order to handle them in the caller method (as in that context you have resources for handling those exceptions).

An Exception Handling Class

What is the best practice for handling exceptions without having to put try/catch blocks everywhere?
I had the idea of creating a class that is devoted to receiving and handling exceptions, but I am wondering if its a good design idea. Such a class would receive an exception and then decide what to do with it depending on its type or error code, could even parse the stack trace for specific information, etc.
Here is the basic idea behind and implementation:
public class ExceptionHandler
{
public static void Handle(Exception e)
{
if (e.GetBaseException().GetType() == typeof(ArgumentException))
{
Console.WriteLine("You caught an ArgumentException.");
}
else
{
Console.WriteLine("You did not catch an exception.");
throw e; // re-throwing is the default behavior
}
}
}
public static class ExceptionThrower
{
public static void TriggerException(bool isTrigger)
{
if (isTrigger)
throw new ArgumentException("You threw an exception.");
else
Console.WriteLine("You did not throw an exception.");
}
}
class Program
{
static void Main(string[] args)
{
try
{
ExceptionThrower.TriggerException(true);
}
catch(Exception e)
{
ExceptionHandler.Handle(e);
}
Console.ReadLine();
}
}
I thought this would be an interesting endeavor because you would theoretically only need one or very few try / catch blocks around your main() method calls, and let the exception class handle everything else including re-throwing, handling, logging, whatever.
Thoughts?

There is actually a good reason why you don't see similar designs in production code.
First of all, such a design cannot help you reduce the count of try/catch pairs in your code (this should be obvious). It could help you reduce the number of catch statements for a given try, since you could just catch System.Exception and forward to the ExceptionHandler...
But what next?
Every exception needs to be handled differently. How would the ExceptionHandler know exactly what to do? You could try to solve this in a number of ways, e.g.:
Derive from ExceptionHandler and put the code to handle exceptions in virtual methods
Pass a number of Action<Exception> instances to the handler and have it invoke the proper one
Solution (1) would be worse than what you had before: now you need to create a whole new class for each try block and override a bunch of methods to end up with something worse than you had before (it's not immediately clear how the code in a particular class fits in the flow of your program). It would also leave another important question unanswered: you may need context (access to variables in the current scope) to properly handle the exception. How will you provide access to this context?
Solution (2) would actually end up quite similar to writing the catch blocks that we 've been wanting to avoid (each Action would be effectively the contents of a catch block). We end up doing the same thing, only in a more complicated and verbose manner.
There are also other issues:
What should ExceptionHandler do if it cannot handle the exception? Throwing it again will cause you to lose the original stack trace, in effect destroying all the good information in there.
What if there's a bug in ExceptionHandler? You can truse a try/catch. Can you trust code you wrote yourself to the same degree?
As for the ExceptionThrower... what benefit could it possibly offer over throw new Exception();?
Exception handling is a complicated matter already, and it's difficult enough to get it right without adding extra gears to the machine. Especially if they don't buy you anything new. Don't do it.

OK, this is probably not the answer you want but...
I am generally allergic towards the idea of a general exception handling class. You can almost hear how it is a contradiction in itself. An exception is an exceptional event. Exceptional events cannot be handled in a general manner, but needs tailored handling wherever they may appear, which essentially means that your code should to two things:
be defensive about any input in order to avoid exceptions in the first place
put try..catch blocks wherever it makes sense to catch and handle an exception (note that this means that you should not have try..catch blocks in all methods)
So, where does it make sense to catch and handle an exception? In short, where your code has knowledge that makes it capable of handling the exception. If it does not, let the exception bubble upwards to the caller. The only place where I think you should catch all exceptions and have some generic default behavior around what to do, it at the top level of your app. That is typically the UI.

Sorry, this is not a good idea. When you catch an exception in your code with a normal try/catch block surrounding the relevant section, you get to use two critical pieces of information to deal with the problem: the type of exception, and also where the exception occured.
With your arrangement, you have to deal with all exceptions knowing only what type of exceptions they are. You no longer know where the exception actually occured, so you really can't do anything about the problem other than to log it or show a message to the user.
Moreover, try/catch blocks often also include a finally block, in which you can make sure things happen even if an exception is thrown (like closing streams etc.). You don't have any way in your arrangement of dealing with this.
Proper exception handling can be tricky, and there is no magic bullet that will make it simple and straightforward. If there were, .Net would have already incorporated it.

We have a class in our code-base that has a pretty similar signature to the one you have proposed and I can tell you now that it has only bough misery and suffering!
Why do you have so many try-catch blocks in your code? Can you give some examples? Exceptions by their very nature "Exceptional", i.e.not that frequent! Not only should you not be catching exceptions that frequently, but also every exception is different and the same boilerplate code that works in one situation probably isn't suitable in many other situations.
Nobody said that exception handling was easy (or produced compact code) - you should think carefully about each situation you need to catch an exception and handle it appropriately - avoid catching exceptions that you don't need to handle.

Exception Handling in C# with Entity Framwork 4

I use asp.net 4, c# and ef4.
I would like to know what is the best way to catch an generic Exception from Entity Framework.
At the moment I use Exception it is appropriate?
How catch a more specific one?
Thanks for your time.
try
{
context.DeleteObject(myLockedContent);
context.SaveChanges();
}
catch (Exception)
{
e.Cancel = true;
}

It's rarely good to catch generic exceptions and just cancel them. Exceptions are there to help you ensure you code can act appropriately.
You can catch specific exception types just as you have for the generic (albeit with the identifier you have missed on your example) thus:
catch (OptimisticConcurrencyException ex)
{
// Do some real work to resolve the exception
}
The exception type specified in the catch statement tells the runtime to catch that specific and any child exceptions. As a result you need to organise your catch statements from the most specific exception to the least, i.e. :
catch (OptimisticConcurrencyException ex)
{
// Do some real work to resolve the specific exception
}
...
catch (Exception ex)
{
// Do some real work to resolve the generic 'catch-all' exception
}

Do not do that.
You are hiding errors which could severely affect the reliability of your application. An exception is thrown for a reason, just continuing on like nothing have happened is just wrong.
You're method cannot return the result as promised, which will affect all code that use it. But the calling methods will not know about the exception and will in worst case continue as nothing have happened and therefore produce undesired results.
You should only use catch all
a) when wanting to wrap exceptions at layer boundaries (but do include the original exception).
b) when the exception have propagated to the top layer (which would terminate your application if the exception is not caught).
Other than that, only catch exceptions when you can handle them. That means that you, by catching the exception, can return the result that the caller expects.

the way you are catching in your example is bad, always log the exception somewhere and somehow, for example on a text file or to an SMTPAppender, you can use Log4Net and get it running in very short time with minimal coding from your side.
Said so, it really depends if you want to handle different exceptions differently, for example if a file was not found you can decide to create it or to tell the user to do something, if the more general exception is thrown you may act differently...
just keep in mind you should put all your catch clauses from the more specific to the more generic one, in your example, if you have multiple catches, the one you wrote should be put in the end.

How often should I use try and catch in C#?

When writing a C# application whose #1 priority is to never crash, how often should I used a try-catch block?
Can I encapsulate all the statements in a method in try-catch blocks?
public void SomeMethod()
{
try
{
// entire contents of the function
// library calls
// function calls
// variable initialization .. etc
}
catch (Exception e)
{
// recover
}
}
What are the downsides to wrapping everything in try-catch blocks?

The only down side is when an exception is actually thrown. There is no overhead for wrapping the code, except for when exceptions occur.
Also, you don't want to use try/catch for control flow. Consider this (bad code):
try {
FileStream fs = File.Open("somefile.txt", FileMode.Open);
} catch (Exception ex) {
MessageBox.Show("The file does not exist. Please select another file");
}
You'll get more performance from some thing like File.Exists. such as:
if(!File.Exists("somefile.txt"))
MessageBox.Show("The file does not exist.")
EDIT:
found the MSDN direct quote:
Finding and designing away
exception-heavy code can result in a
decent perf win. Bear in mind that
this has nothing to do with try/catch
blocks: you only incur the cost when
the actual exception is thrown. You
can use as many try/catch blocks as
you want. Using exceptions
gratuitously is where you lose
performance. For example, you should
stay away from things like using
exceptions for control flow.

This is a big topic. Start here for some excellent discussion of Exception handling best practices and be prepared for a religious war...
Code Analysis Team Blog
Martin Fowler - Fail Fast
MSDN on Exception Handling
Checked vs Unchecked Exceptions
My own opinion is that for the most part you use "try/finally" a lot, but "catch" very little. The problem is that if you attempt to catch and handle Exceptions in the wrong instances, you may inadvertently put your application in a bad state. As a rule, use dev and test to learn where you actually need to handle an exception. Those will be places that you can't check. i.e. you shouldn't really need to handle nullreference or filenotfound because you can proactively check for those. Only exceptions you know may happen, but you can't do anything about. Beyond that, for the sake of your data's state, let it crash.
If you are swallowing exceptions, it generally means you don't understand your program or why you are getting an exception. Catching System.Exception is the poster child of code smells...

Actually, I very rarely use a catch block except for logging purposes. finally is much more common for me. Most times, lock or using do everything I can usefully do (and indeed, that is a finally also).
Eric Lippert has a blog entry on exceptions that may be useful.

The key to this question is the following line:
// recover
To be able to recover, you have to know what and how to recover. And that's assuming it is possible to recover, which quite frequently it isn't.
You should only use the catch part of try/catch/finally to swallow an exception when you know how to handle the exception, when you know how to recover from it, and when you're sure you can do so without leaving the application in an inconsistent or invalid state.
If you can do this for all possible exceptions in all method calls in your application then go right ahead, otherwise you might need to re-think your #1 priority (sometimes failing fast is a better options than trying to keep an application alive when something has gone wrong, and having a much harder to debug crash later on).

Generally IMO it is better to put smaller chunks that are out of your control in a try catch. If you say:
try
{
//anything that could possibly go wrong
//This kind of thing is only good for Logging IMO and could be done in
//Global.asax
}
How could you possibly know what to do in your catch method cause it could be anything...
Its much better to go:
try
{
//divide user imputs
}
catch(DivideByZeroException)
{
// tell user bad inputs ect....
}
catch (Exception e)
{
//If you choose to throw the exception you should
//***********************
throw;
//VS
throw ex; //Throw ex will restart the stack trace
// recover
}
finally
{
//Clean up resources and continue
}
In which finally is always run

There is performance overhead for try blocks, if you do that your entire function will run slower then it otherwise would. catch (Exception e) is also a bad idea, if you catch you want to do something useful with what you caught, and if you catch all exceptions it is impossible to know what you should be doing.

You can do this, although almost in any given environment you're running in, there's a global exception handler where you can catch and handle even unknown errors.
For web apps, there's the Global.asax, for a console program, just wrap your Main() in a try/catch, for services, there's AppDomain.CurrentDomain.UnhandledException, etc.
You should wrap sections where you can predict what the exception might be in more specific blocks, but the global exception handlers should greatly simplify your code and help you out.

You should only catch and stop the exception without rethrowing it if you can meaningfully handle it. Otherwise it is an error and it should propagate up.
I assume that when they say "this app should never crash" there is an implicit requirement that it behaves correctly. Only stoping exceptions that are meaningfully handled satisfies the behaving correctly requirement.
Typically an app will have a single top-level catch block to catch and log unhandled exceptions. These should occur infrequently (and perhaps your requirement can be interpreted to mean these should not happen at all). If you catch and stop exceptions anywhere else in your code, you risk not discovering these problems. If you catch log and stop in lots of other parts of your code, you have a poorly constructed app from the perspective of separation-of-concerns.

I try to avoid try catch blocks generally. I prefer to use blocks to force the user into obeying the rules of an application. For example, if a user should only enter an int that is equal to or less than an int x I'd use:
if (input > x)
{
Console.WriteLine("Invalid input. Please enter a number that is equal to or less than x.");
{...}
}
rather than using:
catch (IndexOutOfRangeException)
{
//error message here
}
From my own personal experience I find it easier to write as you can avoid encapsulating code in a try block (guarding code).
Of course, there will always be times where using try catch is unavoidable - I just like to work around it where possible.

Our current application has a similar mandate: Never crash. Always back out gracefully. To do this, you have to make sure that every line of code is either enclosed in a try-catch block or only called by code that its exceptions can bubble up into.
Also, to protect against uncaught exceptions, we attach an UnhandledExceptionEventHandler to AppDomain.CurrentDomain.

You should use them anytime a piece of code can thrown an exception.
You have to be careful, catching general exceptions is never a good idea. You have to decide which layer you want to handle them.
Meaning the deeper you are you want to catch very specific excpetion and go more general. In a database catch the SqlException. As you go higher in the stack you catch more exceptions to finally catching the general exception at the very top.
That way you can deal with each exception on a case by case basis. A general exception you aren't going to know what to do with.

public void functionName
{
try
{
//your codes
//sometimes 'return' shows exceptions
}
catch(Exception e)
{
messagebox.show(e.Tostring()); //to know what is the exception
}
finally
{
}
}

try catch in c#:
try{
}
catch (NullReferenceException en)
{
}