In my understanding you would like to catch all exceptions that might
happen, log them, even if you forget try/catch block.

As far as I know, there is no general error handling if an exception is
thrown. You need to have a try/catch for that in every routine you expose
from your class library.

On top of that, I would mention, that it's generally NOT recommended to
handle ALL exceptions. You should handle only those exceptions you KNOW how
to handle properly. All other should propagate up the call stack. If you
would like to log them, then maybe an idea would be to call them and rethrow
after logging.

A nice discussion of exception handling in the above context is here:

http://blogs.msdn.com/fxcop/archive/2006/06/14/FAQ_3A00_-Why-does-FxCop-warn-aga
inst-catch_2800_Exception_29003F00_-_2D00_-Part-1-_5B00_Nick-Guerrera_5D00_.aspx

Best regards,
Cezary Nolewajka

Consultant | Microsoft Services | Microsoft | Poland

On Jan 22, 1:10 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:

Hai,

    thanks for your immd. reply.

    My requirement is, in my "class library", if i forget the
"exception handler" in any one of the place, where we can expect the
exception. That exception should be logged in to a text file, instead
of stop the execution.

eg.,

  namespace ECommerce{

   public class CardProcessor{

       public void MethodCaller(){
           CalledMethod();
       }

       public void CalledMethod(){
          throw new Application("Error Raised");
       }

   }
   }

    If i used this class library in my project, what will happen? I
am thinking that, it will stop the execution. If my thinking is
correct, then it would not stop the execution, instead of that, the
error will be logged in a text file.

    I think, now you will understand my requirement.

Regards,
Raj

I would suggest rather :
- each application should have a global exception handler that is
responsible to handle exceptions not handled locally (wether or not it comes
from itself or from third party libraries)

If you do what you want (not sure you can have a class library level
exception handler anyway) :
- your application will continue if you have an error. It could make things
worse
- you'll hide errors from the application that has no choice about how to
handle those hidden exceptions
- you'll hide also them from the developper that will have to check this
file for errors

IMO a class library should :
- handle exceptions for which you *really* know you can do something or to
clean up resources (but still let the exception to be propagated to the
caller)
- tihis is not the class library job to deal with legitimate exceptions that
could happen. IMO this is the job of the main application (using a global
exception handler as a safety net and possibly local exception handler where
appropriate)...

--
Patrice

On Jan 22, 1:10 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:

Hai,

    thanks for your immd. reply.

    My requirement is, in my "class library", if i forget the
"exception handler" in any one of the place, where we can expect the
exception. That exception should be logged in to a text file, instead
of stop the execution.

eg.,

  namespace ECommerce{

   public class CardProcessor{

       public void MethodCaller(){
           CalledMethod();
       }

       public void CalledMethod(){
          throw new Application("Error Raised");
       }

   }
   }

    If i used this class library in my project, what will happen? I
am thinking that, it will stop the execution. If my thinking is
correct, then it would not stop the execution, instead of that, the
error will be logged in a text file.

    I think, now you will understand my requirement.

Regards,
Raj

You should definitely read the other replies...you've gotten three other  
responses, all of which include good information.

That said, there's one possibility that doesn't seem to have been covered  
explicitly, and which you _might_ be asking about.  That is, you're trying  
to protect against your own errors, to catch exceptions that should not  
have happened or which should have happened but which your own library  
should have recovered from and didn't.

Now, this scenario doesn't change the other advice much.  But it's at  
least a potentially more worthwhile goal than trying to catch all  
exceptions.  After all, a good library will only throw an exception either  
when the client code does something wrong, or when the library was asked  
to do something that isn't possible and throwing an exception is a  
well-defined response to that.  All the more reason to dissuade you from  
doing it.  :)

The problem is that there's no global way to catch exceptions.  To prevent  
a thread or process from being terminated due to an exception, you really  
need to handle it.  There are "unhandled exception" events you can  
subscribe to, but those don't catch exceptions...they just provide  
notification of them and subscribing to the events won't prevent the  
exception from causing what it would otherwise cause.

So you're still stuck putting exception handlers in every single one of  
your public methods and properties for your library.  And in addition,  
since there are going to be some exceptions that _should_ be allowed back  
through to the client of the library, you need to include some mechanism  
to distinguish between the two.  One mechanism for this might be to create  
a new exception class (call it something like "PassthroughException") that  
when caught at the top-level of the call chain in your library (i.e. one  
of those public methods or properties) is a signal to that exception  
handler that it _should_ rethrow the exception.

There are problems with this solution though.  One being that it means  
none of your public methods or properties can themselves call another  
public method or property.  The property question is especially  
problematic, since using property accessors rather than the underlying  
fields is desirable whether the code is the client code or the library  
itself.  Another problem is that while you can rethrow the underlying  
exception (set the inner exception when wrapping in your pass-through  
exception, and then throw that inner exception again from the top-level  
method or property), doing so will (if I recall correctly) rewrite the  
stack trace for the exception, hiding useful information.

IMHO, the bottom line is that you really just need to make sure you don't  
throw exceptions that are your fault.  As others have pointed out, if you  
are handling these unexpected exceptions and writing them to a log file,  
you're just sweeping bugs under the rug.  An unexpected exception is a  
bug, and once one happens you have no way to know that you're not going to  
cause something else to be wrong later on.  Data could wind up corrupted,  
or the library could stop doing the right thing, or any number of other  
things could go wrong.

So, in spite of the apparent usefulness of doing so, do pay heed to the  
other advice given.  Don't handle an exception unless you can _truly_  
handle it (and by that I mean, your code understands the exception and  
knows what the appropriate response to it is).  Other exceptions, leave it  
up to the client code to deal with, and preferably they should either  
figure out how not to cause the exception to happen (in cases where their  
code did something wrong) or they should tell you about the exception so  
that you can fix the bug in your library that caused it (in cases where  
your library did something wrong).

Pete