Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

С учетом данных определений должно быть ясно, что структурированная обработка исключений в .NET предлагает подход, предназначенный для выявления исключительных ситуаций в среде выполнения. Однако и в случае программных и пользовательских ошибок, которые ускользнули от вашего внимания, среда CLR зачастую генерирует соответствующее исключение, идентифицирующее проблему. Для этого библиотеки базовых классов .NET определяют целый ряд исключений, таких как FormatException, IndexOutOfRangeException, FileNotFoundException, ArgumentOutOfRangeExсeption и т.д.

Перед тем как углубиться в детали, давайте определим формальную роль структурированной обработки исключений и выясним, чем такая обработка отличается от традиционного подхода в деле исправления ошибок.

Замечание.Чтобы сделать примеры программного кода, используемые в данной книге, как можно более конкретными, в них обрабатываются не асе возможные исключения, генерируемые соответствующими методами из библиотек базовых классов. Приемы, представленные в этой главе, вы можете использовать в своих реальных проектах по своему усмотрению.

До появления .NET обработка ошибок в операционной системе Windows представляла собой весьма запутанную смесь технологий. Многие программисты создавали свою собственную логику обработки ошибок, используемую в контексте приложения. Например, группа разработчиков могла определить набор числовых констант, представляющих известные сбойные ситуации, и использовать эти константы в качестве возвращаемых значений метода. Для примера взгляните на следующий фрагмент программного кода, созданного на языке C.

/* Типичный механизм учета ошибок в C. */

#define E_FILENOTFOUND 1000

int SomeFunction() {

// Предположим, что возникла ситуация, в результате

// которой возвращается следующее значение.

return E_FILENOTFOUND;

}

void Main() {

int retVal = SomeFunction();

if (retVal == E_FILE_NOTFOUND) printf("Не найден файл…");

}

Такой подход следует признать далеким от идеального, если учесть тот факт, что константа E_FILENOTFOUND является лишь числовым значением, а не информационным агентом, предлагающим решение возникшей проблемы. В идеале хотелось бы получать название ошибки, сообщение о ней и другую полезную информацию в одном пакете вполне определенного вида (и именно это предлагается в рамках структурированного подхода к обработке исключений).

В дополнение к приемам самого разработчика, Windows API предлагает сотни кодов ошибок, которые поставляются в виде #define, HRESULT, а также в виде многочисленных вариаций булевых значений (bool, BOOL, VARIANT_BOOL и т.д.). Многие разработчики программ на языке C++ (а также VB6) в рамках модели COM явно или неявно применяют ограниченный набор стандартных COM-интерфейсов (например, ISupportErrorInfo, IErrorInfo, ICreateErrorInfo), чтобы предоставить COM-клиенту информацию об ошибках.

Очевидной проблемой этой уже устаревшей схемы является отсутствие симметрии. Каждый из подходов более или менее укладывается в рамки своей конкретной технологии, конкретного языка и, возможно, даже в рамки конкретного проекта. Чтобы положить конец неуемному буйству разнообразия, платформа .NET предлагает стандартную технологию генерирования и выявления ошибок среды выполнения: структурированную обработку исключений – СОИ (Structured Exception Handling – SEH).

Преимущество предлагаемой технологии заключается в том. что теперь разработчики могут использовать в области обработки ошибок унифицированный подход, общий для всех языков, обеспечивающих поддержку .NET. Таким образом, способ обработки ошибок в C# оказывается синтакcически аналогичным такой обработке и в VB .NET, и в C++ с управляемыми расширениями. При этом синтаксис, используемый для генерирования и выявления исключений между компоновочными блоками и границами систем, тоже оказывается одинаковым (и это является дополнительным преимуществом).

Еще одним преимуществом обработки исключений в .NET является то, что вместо передачи простого "зашифрованного" числового значения, идентифицирующего проблему, исключения представляют собой объекты, содержащие понятное человеку описание ошибки, а также подробную "копию" содержимого стека вызовов в момент возникновений исключительной ситуации. К тому же вы имеете возможность предоставить конечному пользователю ссылку с адресом URL, по которой пользователь может получить подробную информацию о соответствующей проблеме.

При создании программ с применением структурированной обработки исключений предполагается использовать следующие четыре взаимосвязанных элемента:

• тип класса, который предоставляет подробную информацию о возникшей исключительной ситуации;

• член, который генерирует, или направляет (throw) вызывающей стороне экземпляр класса, соответствующего исключительной ситуации:

• блок программного кода вызывающей стороны, в котором был вызван генерирующий исключение член;

• блок программного кода вызывающей стороны, в котором выполняется обработка, или захват (catch), данного исключения.

В языке программирования C# предлагаются четыре ключевых слова (try, catch, throw и finally), с помощью которых генерируются и обрабатываются исключения. Тип, представляющий соответствующую проблему, является классом, производным от System.Exception (или его потомком). С учетом этого давайте выясним роль указанного базового класса.

Все исключения, определенные на уровне пользователя и системы, в конечном счете получаются из базового класса System.Exception (который, в свою очередь, получается из System.Object). Обратите внимание на то, что некоторые из указанных ниже членов виртуальны и поэтому могут переопределяться производными типами.

public class Exception:ISerializable, _Exception {

public virtual IDictionary Data { get; }

protected Exception(SerializationInfo info, StreamingContext context);

public Exception(string message, Exception innerException);

public Exception(string message);

public Exception();

public virtual Exception GetBaseException();

public virtual void GetObjectData(SerializationInfo info, StreamingContext context);

public System.Type GetType();

protected int HResult { get; set; }

public virtual string HelpLink { get; set; }

public System.Exception InnerException { get; }

public virtual string Message { get; }

public virtual string Source { get; set; }

public virtual string StackTrace { get; }

public MethodBase TargetSite { get; }

public override string ToString();

}

Как видите, многие свойства, определенные в классе System.Exception, доступны только для чтения. Причиной этого является тот простой факт, что производные типы обычно предусматривают для каждого свойства значение по умолчанию (например, для типа IndexOutOfRangeException принятым по умолчанию сообщением является "Index was outside the bounds of the array", т.е. "Выход индекса за границы массива").