How to do Exception Handling & Tracing in C#_问答_开发者

I am reading some C# books, and got some exercise don't know how to do, or not sure what does the question mean.

Problem:

After working for a company for some time, your skills as a knowledgeable developer are recognized, and you are given the task of “policing” the implementation of exception handling and tracing in the source code (C#) for an enterprise application that is under constant incremental development. The two goals set by the product architect are:

100% of methods in the entire application must have at least a standard exception handler, using try/catch/finally blocks; more complex methods must also have additional exception handling for specific exceptions
All control flow code can optionally write “tracing” information to assist in debugging and instrumentation of the application at run-time in situations where traditional debuggers are no开发者_开发百科t available (eg. on staging and production servers).

(I am not quite understand these criterias, I came from the java world, java has two kind of exception, check and unchecked exception. Developer must handle checked exception, and do logging. about unchecked exception, still do logging maybe, but most of the time we just throw it. however here comes to C#, what should I do?)

Question for Problem:

List rules you would create for the development team to follow, and the ways in which you would enforce rules, to achieve these goals.
How would you go about ensuring that all existing code complies with the rules specified by the product architect; in particular, what considerations would impact your planning for the work to ensure all existing code complies?

As you mentioned Java has checked and unchecked exceptions. For checked exceptions you have to either declare your method throws it, or handle the exception in the method. C# does not have that limitation, your method doesn't have to declare what exception it could possibly throw.

100% of methods in the entire application must have at least a standard exception handler, using try/catch/finally blocks; more complex methods must also have additional exception handling for specific exceptions

This seems like a stupid requirement. If you have no meaningful way to recover from an exception and continue executing normally, you would ideally allow the exception to bubble up the stack unimpeded. That way when you log the exception (right before shutting down gracefully, or not so gracefully) you'll have a full stack-trace of what exactly caused the exception. It is a very common mistake (from the code I've seen) to use pokemon exception handling and logging the exceptions too early (so you know something bad happened but not what piece of code triggered it.

You should also take a look at this list of similar question for a good overview of good exception handling practices.

And for good measure Vexing exceptions.

After you define your application architecture, you should determine how the exceptions generated by your application will be handled. The strategy should be to meet all security, privacy, and performance requirements. The following are general guidelines for an exception handling strategy:

Do not catch exceptions unless some kind of value can be added. In other words, if knowing about the exception is of no use to the user, to you, or to the application, do not catch it.
Do catch exceptions if you want to retry the operation, add relevant information to the exception, hide sensitive information contained in the exception, or display formatted information.
Generally, handle exceptions only at an application boundary (such as the top of a logical layer, tier, the boundary of a service, or at the top of a UI layer). Also, replace exceptions that contain sensitive information with new exceptions that contain information that can be exposed safely outside the current boundary.
Do not propagate sensitive information across trust boundaries. This is a standard security consideration, but it is frequently overlooked when dealing with exception information. Instead, replace exceptions that contain sensitive information with new exceptions that contain information that can be exposed safely outside the current boundary.
Make exceptions as accurate as possible and allow for specific actions to be taken when the exception is raised. Sometimes this may require writing custom exceptions with the required attributes.
Error messages that are displayed to users should be relevant and they should suggest the corrective action to take. In most cases, user-displayed error messages should never contain sensitive information, such as stack traces or server names.