. NET Design Specifications chapter 7th: exceptions,. net Design Specifications

. NET Design Specifications chapter 7th: exceptions,. net Design Specifications
Chapter 4: Exceptions

Exceptions are well integrated with various object-oriented languages.

Exceptions enhance API consistency.

When an error is reported using the return value, the error handling code is always close to the code that may cause the error.

It is easier to implement code-based error handling.

Error Codes are easy to ignore and often ignored.

An exception can contain a wealth of information to describe the cause of the error.

An exception allows you to define a handler for an unhandled exception.

An exception can contain a wealth of information to describe the cause of the error.

An exception allows you to define a handler for an unhandled exception.

Exceptions are helpful for detection.

 

7.1 throw an exception.

Do not return error codes.

The operation fails to be reported by throwing an exception.

Consider terminating the process by calling System. Environment. FailFast when the Code encounters a serious problem and cannot be safely executed. Do not throw an exception.

Do not use exceptions in the normal control flow.

Consider the impact of throwing an exception on performance. For most applications, throwing 100 exceptions per second may seriously affect performance.

You need to write documents for all exceptions and use them as part of the contract-if an exception is thrown because it violates its contract when a public member is called (non-system failure ).

Do not let public members decide whether to throw an exception based on a certain option.

Do not use exceptions as return values or output parameters of public members.

Consider using auxiliary methods to create exceptions.

Do not throw an exception in the exception filter.

Avoid explicitly throwing exceptions from the finally code block. It is acceptable that an exception is thrown by other methods when other methods are called.

　

7.2 select an appropriate type for the thrown exception

Do not create a new exception type to report usage errors. In this case, an existing exception in the framework should be thrown.

Consider creating and throwing a custom exception for a program error-if it is handled differently than other exceptions. Otherwise, an existing exception should be thrown.

Do not create a new exception type-if the handling of this error is no different from the existing exception in the framework. In this case, an existing exception in the framework should be thrown.

You need to create a new exception type to deliver a unique program error-if the exception already exists in the framework cannot be used to deliver the error.

Avoid designing APIs that may cause system failures. If such a failure may occur, Environment. FailFast should be called when the system fails, and no exception should be thrown.

Do not create and use new exceptions just to own your own exceptions.

Use the appropriate and most targeted (bottom-layer derived class) exception.

Rich and meaningful error messages should be provided to developers when an exception is thrown.

Make sure that the syntax of the exception message is correct.

Make sure that each sentence in the exception message has a full stop.

Avoid using question marks and exclamation points like exception messages.

Do not leak security messages in exception messages without permission.

Consider localized exception messages thrown by components-components that can be used by developers who want to bathe in other languages.

Do not swallow errors when the Framework Code captures exceptions with unknown types (such as System. Exception, System. SystemException, and so on.

In the application code, avoid swallowing errors when capturing exceptions of Certain types (such as System. Exception, System. SystemException, and so on.

Do not exclude any special exceptions-if the purpose of writing a catch code block is to transfer exceptions.

Consider capturing a specific type of exception-if you understand the cause of the exception in a specific environment, and can make appropriate responses to the error.

Do not capture exceptions that should not be caught. Generally, exceptions should be allowed to be passed up the call stack.

Try-finally should be used for cleanup to avoid try-catch. For well-written exception codes, try-finally is much more frequently used than try-catch.

Use an empty throw statement to capture and throw an exception again. This is the best way to keep the abnormal call stack unchanged.

Do not use catch blocks without parameters to handle exceptions that do not comply with CLS specifications (not exceptions derived from System. Exception ).

Consider appropriate encapsulation of exceptions thrown at a lower level-if exceptions at a lower level do not make sense in a higher level runtime environment.

Avoid capturing and encapsulating exceptions with unknown types.

Internal exceptions must be specified when exceptions are encapsulated.

 

7.3 use of standard exception types

Do not throw System. Exception or System. system1_tio Exception.

Do not catch System. Exception or System. SystemException exceptions in the Framework Code unless you intend to throw them again.

Avoid System. Exception or EN en. SystemException exceptions, unless they are in the Exception processor at the top layer.

Do not throw System. ApplicationException or derive a new class from it.

An InvalidaOperationException is thrown-if the object is in an incorrect state.

An ArgumentException exception or its subtype is thrown when an invalid parameter is passed in. If possible, try to use the exception type at the end of the inheritance level.

You must set the ParamName attribute when throwing an ArgumentException exception or its subclasses.

In the Property setter, value is used as the name of the value implicit parameter.

Do not allow public APIs to explicitly or implicitly throw NullReferenceException, AccessViolationException, or IndexOutOfRangeException. These exceptions are thrown by the execution engine. In most cases, they indicate code defects.

Do not explicitly throw an StackOverflowException exception. Only the CLR can explicitly throw this exception.

Do not catch StackOverflowException exceptions.

Do not explicitly throw an OutOfMemoryException. Only CLR can throw an exception.

Do not explicitly throw ComException, ExecutingEngineException, and SEHException. Only CLR can throw these exceptions.

 

7.4 Design of custom exceptions

A new Exception is derived from the System. Exception or other common Exception base classes.

Avoid too deep inheritance layers.

Use the suffix "Exception" when naming Exception classes.

To serialize exceptions. This is required to enable normal use of exceptions across application domains and remote boundaries.

Provide the following frequently-used constructor for all exceptions (at least.

To report security-related messages through a ToString override method, you must first obtain the appropriate license.

You must store security-related information in a private exception State and ensure that only trusted code can obtain this information.

Consider defining attributes for exceptions so that you can obtain additional information related to exceptions in addition to message strings from the program.

　　

7.5 exceptions and Performance

Do not use error codes because exceptions may negatively affect performance.

Consider using Tester-Doer mode in members to avoid performance problems caused by exceptions-if Members may throw exceptions in common scenarios.

Use the Try-Parse mode in members to avoid performance problems caused by exceptions. If a Member throws an exception in common code.

To implement the Try-Parse mode, use the "Try" prefix and the boolean type as the return type of the method.

You need to provide a corresponding member that will throw an exception for each Try-Parse mode method.