Things to Avoid When Throwing Exceptions

The following list identifies practices to avoid when throwing exceptions:

· Exceptions should not be used to change the flow of a program as part of ordinary execution. Exceptions should only be used to report and handle error conditions.

· Exceptions should not be returned as a return value or parameter instead of being thrown.

· Do not throw System..::.Exception, System..::.SystemException, System..::.NullReferenceException, or System..::.IndexOutOfRangeException intentionally from your own source code.

· Do not create exceptions that can be thrown in debug mode but not release mode. To identify run-time errors during the development phase, use Debug Assert instead.

Defining Exception Classes

Programs can throw a predefined exception class in the System namespace (except where previously noted), or create their own exception classes by deriving from ApplicationException. The derived classes should define at least four constructors: one default constructor, one that sets the message property, and one that sets both the Message and InnerException properties. The fourth constructor is used to serialize the exception. New exception classes should be serializable. For example:

[Serializable()] public class InvalidDepartmentException: System.Exception { public InvalidDepartmentException() { } public InvalidDepartmentException(string message) { } public InvalidDepartmentException(string message, System.Exception inner) { }   // Constructor needed for serialization // when exception propagates from a remoting server to the client. protected InvalidDepartmentException(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context) { } }

New properties should only be added to the exception class when the data they provide is useful to resolving the exception. If new properties are added to the derived exception class, ToString() should be overridden to return the added information.

Чего следует избегать при генерации исключений

Ниже приводятся рекомендации по тому, чего следует избегать при генерации исключений:

· Исключения не рекомендуется использовать для изменения потока программы в рамках обычного выполнения. Исключения используются только для сообщения о состояниях ошибки и их обработки.

· Исключения не должны возвращаться в качестве возвращаемого значения или параметра вместо генерации.

· Не рекомендуется специально генерировать System..::.Exception, System..::.SystemException, System..::.NullReferenceException или System..::.IndexOutOfRangeException из собственного исходного кода.

· Не рекомендуется создавать исключения, которые могут быть сгенерированы в режиме отладки, а не в режиме выпуска. Чтобы определить ошибки времени выполнения на этапе разработки, используйте Debug Assert.

Определение классов исключений

Программы могут генерировать предопределенный класс исключений в пространстве имен System (если специально не обозначено иное), или создавать собственные классы исключений путем наследования от ApplicationException. Производные классы должны определять, по меньшей мере, четыре конструктора: один конструктор по умолчанию, один конструктор, задающий свойство сообщения, и еще один, задающий свойства Message и InnerException. Четвертый конструктор служит для сериализации исключения. Новые классы исключений должны быть сериализуемыми. Пример.

ß-----

 

Новые свойства следует добавлять к классу исключений только в том случае, если данные в них могут помочь в разрешении исключения. При добавлении новых свойств в производный класс исключений, ToString() должно быть перезаписано для возврата добавленных сведений.