I am researching about the Exception handling application block and I read a paragraph from the Microsoft page: When Should I Use the Exception Handling Application Block?
The original content:
Limitations of the Exception Handling Application Block
The Exception Handling Application Block is a complement to exception
handling recovery code; it is not a replacement for it. If exceptions
occur because of truly unusual circumstances, it can be impossible for
an application to recover gracefully and finish the unit of work it
has started. However, it is sometimes possible to recover. An example
is an exception that occurs because a file is locked. The recovery
code might direct the application to retry the file after waiting for
some period of time.In such cases, exception handling recovery code should be implemented
within the application code; it should not be implemented as a handler
used by the Exception Handling Application Block. This is because it
requires access to local variables, parameters, and other contextual
data. This data is out of scope and inaccessible to handlers run by
the Exception Handling Application Block.
What does “exception handling recovery code” mean?
An example would be useful too.
Exception handling recovery code would be what’s in your
catchcode block. It could be something that logs the error, looks up a friendly message to display to the user, or retries some process etc.From that quoted text in your question:
See on MSDN: Exceptions and Exception Handling.
An example of why you should handle exceptions as soon as possible, rather than in the exception handling application block, as it says, could be where you need access to local variables. E.g. you try and open a file, but get an error. It might be nice to let the user know which file you couldn’t open. For that you need access to the variables within the method that opens the file. If you wanted to retry opening the file you’d have to do that there too.