What's the definition/example of an exception which cannot be handled (outside of framework exceptions)?

As it is said that an exception should开发者_开发问答 only be caught if it can be handled, what is an example of an exception which cannot be handled (outside of things like OOM, BadImageFormat, etc).

I'm under the impression that an exception which is logged is an exception that has been handled, or does handling mean doing some sort of corrective action (e.g. if a network share is down, try a backup share or mount another, etc)?

Examples of exceptions which can and can't be handled greatly appreciated.

Thanks

---

Handling (to me) means taking appropriate action to resume the flow of your application. If you rethrow the exception, then you haven't handled it. Logging would be one case where you might rethrow an exception.

An example of a exception that can be handled: you are running a service that notifies a particular user of an event. You try to use a web service to send a SMS message, this gives an exception (server down, account closed, whatever), so as a fallback you send an email message, that fails with another exception, so you fall back to trying to make a voice call. That succeeds and your customer gets notified of whatever he wanted to know.

An example of an exception that can sometimes be handled and other times not: you get an System Insufficient memory exception. Sometimes you know that you have a lock on something that is large but non-critical, which you could release and then retry, but typically everything that you have an active reference to is something that must have, in which case there's nothing you can really do to recover.

Note that quite frequently, handling means simply returning false for a function that was asked to do something and for which a success/failure is returned. This isn't as useless as it might at first appear, consider this scenario: you make a change to a file, and then tell the application to save the changes. The disk is full or unavailable for some reason. Either will cause an exception. When saving you have isDirty = savefile() , the exception happens inside savefile and is "handled" by savefile by setting the result to false. This allows the application to know (and to show to the user) that the file hasn't been saved.

---

Outside of the key framework exceptions which cannot be caught by the CLR (StackOverflow, OutOfMemory, etc) there are several exceptions that generally should not be caught as they represent developer errors that should be addressed during development. While logging the exceptions can be seen as a mechanism to "handle" the exception, it's only useful if the log files are reviewed for errors.

In general, exceptions like ArgumentNullException, ArgumentException, NullReferenceException, etc should not be caught by developers explicitly, and should be allowed to bubble up so that they can be identified and fixed.