Здравствуйте, друзья.

Поделитесь своим опытом в решении следующей проблемы:

Есть некоторая (моя) функция, которая вызывает методы "родных" объектов .net. Эти методы время от времени бросают исключения. Так вот, не хочется тупо пропускать эти исключения "наверх", а хочется их перехватить, проанализировать и в зависимости от ситуации бросить новое исключение, в которое вложить (as InnerException) ранее перехваченное. То есть хочется примерно такого:

try
{
// ...
}
catch(Exception e)
{
  switch(e.GetIdentifierOfExeption())
  {
  case ExceptionInetifier.DuplicateKeyInDictionary:
    throw new Exception("Недопустимое дублирование ключа конфигурации в строке параметров", e);
    break;

  case ExceptionInetifier.NoKeyIsSpecified:
    throw new Exception("Ключ конфигурации не может быть пропущен", e);
    break;

  default:
// ...   
  }
}

Так вот, проблема возникает с "проанализировать", т.е. создать осмысленный метод расширения класса Exception GetIdentifierOfExeption(). Идея сравнивать тексты сообщений мне кажется бредовой — где гарантия, что в разных версиях (и локализациях) фреймворка эти сообщения будут текстуально совпадать. На мой личный вкус, этот идентификатор должен быть целочисленным, ну в крайнем случае GUID'ом. Дернулся было в сторону GetHashCode(), но быстро понял, что это не то. Этот Хэш идентифицирует сами исключения, а не их типы. В принципе, в некоторых контекстах меня устроило бы свойство HResult:

class utility
{
  public int GetIdentifierOfExeption(this Exception e) { return e.HResult; }
}

Но беда в том, что оно — защищенное. То есть если я унаследую класс от Exception, то в своем производном классе я с ним работать смогу, а вот в базовом классе (и в системных классах-наследниках) — извините. Но ведь получаю я исключения базового класса (точнее, приведенное к базовому классу).

В общем, не знаю, как мне быть. А как подобную задачу решаеите вы?

Здравствуйте, teapot2, Вы писали:

T> а хочется их перехватить, проанализировать и в зависимости от ситуации

Для этого вроде есть типы исключений

try
{
    // ...
}
catch(DuplicateKeyException e)
{
    // ...
}
catch(NullReferenceException e)
{
    // ...
}
catch(Exception e)
{
    // ...
}

Возможно автор спрашивает как различать разные InvalidOperationException
и другие эксепшены подобного типа

Здравствуйте, pugv, Вы писали:

P>Для этого вроде есть типы исключений

P>

P>try
P>{
P>    // ...
P>}
P>catch(DuplicateKeyException e)
P>{
P>    // ...
P>}
P>catch(NullReferenceException e)
P>{
P>    // ...
P>}
P>catch(Exception e)
P>{
P>    // ...
P>}
P>

Это был бы идеальный вариант. Однако он не работает. Например, различные по смыслу системные исключения относятся к одному и тому же типу System.InvalidOperationException. А мне необходимо их различать. Другие предложения?

Здравствуйте, teapot2, Вы писали:

T>Здравствуйте, pugv, Вы писали:

P>>Для этого вроде есть типы исключений

T>Это был бы идеальный вариант. Однако он не работает. Например, различные по смыслу системные исключения относятся к одному и тому же типу System.InvalidOperationException. А мне необходимо их различать. Другие предложения?
А не надо их перехватывать в одном глобальном месте, когда контекст уже потерян. Перехватывайте их в месте в котором тип каждого конкретного InvalidOperationException понятен из контекста, там вы сможете "запаковать" их свой конкретный тип исключения и передать для обработки на уровень выше.

Здравствуйте, teapot2, Вы писали:

T>различные по смыслу системные исключения относятся к одному и тому же типу System.InvalidOperationException. А мне необходимо их различать. Другие предложения?
Сводить свой код к методам, в которых перехват сферического [Something]Exception однозначно говорит о том, что произошло.
Иначе я боюсь себе представить логику, которая отвечает за восстановление после такого Exception.
А еще стоит подумать, не строите ли вы execution flow на исключениях.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Сводить свой код к методам, в которых перехват сферического [Something]Exception однозначно говорит о том, что произошло.
Это не всегда возможно. Тот же InvalidOperationException в одном месте может быть вызван парой-тройкой разных причин.

HL>Иначе я боюсь себе представить логику, которая отвечает за восстановление после такого Exception.
Пара-тройка возможных вариантов не усложнит логику восстановления сильно. Я же не собираюсь в этом месте проверять ВСЕ возможные случаи InvalidOperationException — только те, которые могут возникнуть именно в этом контексте. А вот диагностика действительно необходима разная.

HL>А еще стоит подумать, не строите ли вы execution flow на исключениях.
Разумеется не строю. Задача гораздо скромнее — вместо "System.InvalidOperationException: Sequence contains more than one element" записать в журнал "Строка конфигурации приложения содержит повторяющиеся ключи" или что-то в этом роде.

Здравствуйте, teapot2, Вы писали:

T> Тот же InvalidOperationException в одном месте может быть вызван парой-тройкой разных причин.

Если не сложно, приведите код...

Здравствуйте, teapot2, Вы писали:

Я делал примерно так

Exception ExtractException(Exception ex)
{
  return ex.WrapIf<InvalidOperationException >((e) => e.Message.Contains(someText), (e) => e.InnerException.ToAbortRequest()) 
      ?? ex.WrapIf<FaultOperationException>((e) => e.SourceId != null, (e) => e.ToAbortRequest())
      ?? ex.WrapIf<NotSupportedException>((e) => e.ToAbortRequest())
      ?? ex.WrapIf<TargetInvocationException>((e) => e.InnerException.ToAbortRequest());
}

T>

T>try
T>{
T>// ...
T>}
T>catch(Exception e)
T>{
T>  switch(e.GetIdentifierOfExeption())
T>  {
T>  case ExceptionInetifier.DuplicateKeyInDictionary:
T>    throw new Exception("Недопустимое дублирование ключа конфигурации в строке параметров", e);
T>    break;

T>  case ExceptionInetifier.NoKeyIsSpecified:
T>    throw new Exception("Ключ конфигурации не может быть пропущен", e);
T>    break;

T>  default:
T>// ...   
T>  }
T>}
T>

Здравствуйте, pugv, Вы писали:

T>> Тот же InvalidOperationException в одном месте может быть вызван парой-тройкой разных причин.
P>Если не сложно, приведите код...

В корне неверная постановка вопроса с Вашей стороны. Даже если у меня есть всего лишь смутные подозрения без каких-либо подтверждений, что один тип исключения может соответствовать разным ошибкам, я обязан отработать эту ситуацию. Полагаться на тип исключения можно было бы только тогда, если бы в документации были бы абсолютные гарантии подхода "одна причина — один тип exception". У Вас есть идеи насчет того, кто бы мог дать подобные гарантии? Собственно, вопрос риторический и полагаться целиком только на тип исключения в принципе недопустимо. Вне зависимости от того, смогу ли я привести пример или нет.

Тем не менее, вот пример из реальной жизни (Sharepoint):

// Обработчик события получения почты списком Sharepoint
public override void EmailReceived(SPList list, SPEmailMessage emailMessage, String receiverData)
{
//...
  var oListItem = list.Items.Add();
//...   
  foreach (var att in emailMessage.Attachments)
  {
    long attLength = att.ContentStream.Length;
    byte[] attBody = new byte[attLength];
    att.ContentStream.Read(attBody, 0, (int)attLength);
    try
    {
      oListItem.Attachements.Add(att.FileName, attBody);
    }
    catch(Microsoft.SharePoint.SPException)
    {
// И как мне различать здесь все возможные варианты:
// - Файл с этим именем уже существует;
// - Имя файла или папки содержит недопустимые знаки.  Используйте другое имя;
// ... (еще целая куча вариантов)
// В зависимости от конкретной причины требуются различные действия
    }
  }
  oListItem.Update();
}

Здравствуйте, teapot2, Вы писали:
T>// И как мне различать здесь все возможные варианты:
T>// — Файл с этим именем уже существует;
catch(SPDuplicateValuesFoundException)
T>// — Имя файла или папки содержит недопустимые знаки. Используйте другое имя;
catch(SPFieldValueException)
T>// ... (еще целая куча вариантов)
Ещё целая куча сatch()
T>// В зависимости от конкретной причины требуются различные действия
Не вижу примеров ваших различных действий. Можно их описать?

Здравствуйте, Sinclair, Вы писали:

S>catch(SPDuplicateValuesFoundException)
У меня во всех указанных случаях кидается и ловится SPException. Как Вы можете объяснить тот факт, что вот такой код

catch (Exception e)
{
    ulsLog.Log(e); // это простая обертка вокруг журнала ULS
}

Делает в ULS-журнал Sharepoint вот такую запись:

Microsoft.SharePoint.SPException: Файл с этим именем уже существует
at Microsoft.SharePoint.SPAttachmentCollection.Add(String leafName, Byte[] data)
at EEDC.EmailReceiver.EmailReceiver.EmailReceived(SPList list, SPEmailMessage emailMessage, String receiverData) in C:\Projects\MySolution\MyProject\EmailReceiver.cs:line 90

А также тот факт, что в MSDN есть явное указание на SPException и нет ни малейшего упоминания SPDuplicateValuesFoundException

Иными словами, предложенное Вами решение не работает. За это Вам минус.

S>catch(SPFieldValueException)
Аналогично.

T>>// В зависимости от конкретной причины требуются различные действия[/b]
S>Не вижу примеров ваших различных действий. Можно их описать?

Во-первых, выяснить суть проблемы и дать адекватный ответ отправителю принимаемого сообщения. Не копировать механически сообщение об ошибке из исключения "Файл с этим именем уже существует", а в зависимости от результатов анализа ситуации: "Дубликат файла xxx.yyy в вашем сообщении игнорирован" или "В вашем сообщении встретились аж три различных файла с одинаковым именем xxx.yyy. Второй и третий сохранены в системе под именами xxx(2).yyy и xxx(3).yyy соответственно". Если неверное имя — переименовать и принять, отправив автору сообщения текст примерно такого содержания: "Недопустимое имя вложения в письмо — xxx..yyy, переименовано в xxx.yyy", а для файлов с запрещенными расширениями — отказать в приеме и отправить уведомление типа "Файл xxx.asa не принят, так как файлы с расширением asa запрещены к приему администратором сайта". О переименовании файлов информировать отправителя совершенно необходимо, т.к. потом он будет получать еще много уведомлений по поводу дальнейшей судьбы этих файлов, в том числе и из систем, которым ничего не известно про переименование. И, во-вторых, логика работы существенно зависит от типа ошибки, например, банально — надо ли сохранять файл в списке Sharepoint или нет, зависит от конкретной ошибки. И еще масса тонкостей.

Еще раз всё проверил, добавив в код явный перехват SPDuplicateValuesFoundException. Теперь у меня это выглидит примерно так:

            catch (SPDuplicateValuesFoundException dve)
            {
                ulsLog.Log(TraceSeverity.Medium, 0,
                           "Перехвачено исключение SPDuplicateValuesFoundException", null);
                ulsLog.Log(dve);
            }
            catch (Exception e)
            {
                ulsLog.Log(TraceSeverity.Medium, 0,
                           "Перехвачено исключение Exception", null);
                ulsLog.Log(e);
            }

Как и ожидалось, записи в журнал с фразой "Перехвачено исключение SPDuplicateValuesFoundException" НЕ ПОЯВИЛОСЬ!!!, зато появилась фраза "Перехвачено исключение Exception". Сработал старый добрый catch (Exception e), что также было отдельно подтверждено и под отладчиком. Удивления это не вызывает, так как в MSDN описании исключения SPDuplicateValuesFoundException читаем:

Exception to throw if and only if duplicate values are found while inserting or updating items/documents in a list/document library

Ясно же написано, что исключительно при добавлении документов/элемнтов в библиотеки документов и списки соответственно. Вложения в списки под эту категорию очевидным образом не попадают.

Короче, товарищ Sinclair, вы слегка лажанулись. И "троечку" за свой комментарий не заслужили.

Здравствуйте, teapot2, Вы писали:

T>Иными словами, предложенное Вами решение не работает. За это Вам минус.
Ну, вопрос был про идентификацию типа исключения. Она работает так, как она работает.
Если злой разработчик бросает исключения одного класса, то есть два варианта действий:
1. Писать код вручную на основе цепочки if-ов
2. Перейти на VB.Net, где есть поддержка catch when

S>>Не вижу примеров ваших различных действий. Можно их описать?

T>Во-первых, выяснить суть проблемы и дать адекватный ответ отправителю принимаемого сообщения. Не копировать механически сообщение об ошибке из исключения "Файл с этим именем уже существует", а в зависимости от результатов анализа ситуации: "Дубликат файла xxx.yyy в вашем сообщении игнорирован" или "В вашем сообщении встретились аж три различных файла с одинаковым именем xxx.yyy. Второй и третий сохранены в системе под именами xxx(2).yyy и xxx(3).yyy соответственно".
Хм. Если у вас наличие дубликата — штатная ситуация с документированным поведением, то что вам мешает перед началом операции запросить список файлов, поискать дубликаты, и переименовать файлы так, как надо?

T>Если неверное имя — переименовать и принять, отправив автору сообщения текст примерно такого содержания: "Недопустимое имя вложения в письмо — xxx..yyy, переименовано в xxx.yyy",
То же самое — вы же заранее знаете, какие символы недопустимы (иначе бы у вас не было алгоритма переименования), но почему-то ждёте исключения. Выполните нормализацию, не дожидаясь исключения.

T> а для файлов с запрещенными расширениями — отказать в приеме и отправить уведомление типа "Файл xxx.asa не принят, так как файлы с расширением asa запрещены к приему администратором сайта".
Вот тут уже имеет смысл выделять полученное исключение программным способом. Может быть, для этого есть специфический код ошибки?

Здравствуйте, Sinclair, Вы писали:

S>1. Писать код вручную на основе цепочки if-ов
S>2. Перейти на VB.Net, где есть поддержка catch when
Так именно в этом и заключается проблема. В текущей ситуации различить конкретные причины исключений я могу, только опираясь на текст сообщения об ошибке. Но это — плохой способ, т.к. текст зависит от локализации и легко может измениться в последующих версиях дот-нет-фреймворка. Но, видимо, другого выбора не остается — придется куски текста для опознования ошибок "зашивать" куда-нибудь в ресурсы. Не понимаю, почему мелкомягкие отказались от старого доброго HRESULT — он тут просто незаменим. Тем паче, что он остался в классе System.Exception в качестве защищенного свойства. И, особенно, с учетом того, что некоторые ошибки содержат этот HRESULT внутри как текст в XML-тегах. (!!!) Но при этом недоступен через защищенное свойство Hresult.

S>Хм. Если у вас наличие дубликата — штатная ситуация с документированным поведением, то что вам мешает перед началом операции запросить список файлов, поискать дубликаты, и переименовать файлы так, как надо?
Я просто обязан на это закладываться. Я не знаю, как это получается — мне ни разу не удалось отправить сообщение с одним и тем же дважды вложенным файлом, мой почтовый клиент это не разрешает. Но клиентам это как-то удается, значит, мы обязаны этот случай обработать. Добро пожаловать в реальную жизнь. Предлагаемый Вами способ — не что иное, как дублирование уже реализованной системной функциональности в своем (пользовательском) коде. Со всеми вытекающими. Где гарантия, что результаты моего поиска будут идентичными встроенному? Это не так очевидно, если принять во внимание различные аспекты типа чувствительности к регистру букв и т.д.. Именно поэтому я не буду так делать. Тем более, что совершенно не исключено, что в будущих версиях фреймворка это будет вполне допустимо (как сейчас допустимо дублирование имен файлов в некоторых почтовых клиентах — не знаю, правда, в каких).

T>>Если неверное имя — переименовать и принять, отправив автору сообщения текст примерно такого содержания: "Недопустимое имя вложения в письмо — xxx..yyy, переименовано в xxx.yyy",
S>То же самое — вы же заранее знаете, какие символы недопустимы (иначе бы у вас не было алгоритма переименования), но почему-то ждёте исключения. Выполните нормализацию, не дожидаясь исключения.
Аналогично предыдущему. Встроенные системные алгоритмы подвержены непредсказуемому изменению. Недопустимые сегодня варианты могут стать допустимыми завтра. Переименование может быть очень простым — оставить только заведомо допустимые символы (буквы, цифры, точки, дефисы, знаки подчеркивания) или вообще дать полностью новое имя на базе номера вложения с сохранением одного-двух расширений имени. При этом, если переименование реально не требуется, делать его совершенно незачем. В общем, дублирование на пользовательском уровне системной функциональности я считаю ошибкой проектирования и делать это, разумеется, не буду.

T>> а для файлов с запрещенными расширениями — отказать в приеме и отправить уведомление типа "Файл xxx.asa не принят, так как файлы с расширением asa запрещены к приему администратором сайта".
S>Вот тут уже имеет смысл выделять полученное исключение программным способом. Может быть, для этого есть специфический код ошибки?
Удивительно, что вы не предлагаете это тоже проверять в пользовательском коде. Именно этот случай — наиболее простой для пользовательской реализации, так как список запрещенных расширений файлов можно получить вызовом системной функции. Но, опять же, зачем эту проверку делать мне в своем коде, если уже прекрасно делает за меня система?

На самом деле, у проблемы есть еще один аспект. Способ классификации ошибки только по типу исключения неизбежно приводит к тому, что почти каждый нетривиальный системный вызов придется оборачивать в отдельный try-catch, что, в итоге, приводит к дикому труднопонимаемому спагетти-коду. С моей точки зрения, код гораздо более удобен для понимания и сопровождения, когда все перхваты исключений локализованы в минимальном количестве мест. Собственно, ради этого исключения и придумали, ибо в языках без механизма исключений приходилось после каждого вызова системных функций анализировать код возврата.

Кратко подведу итоги темы:
Поскольку, как выяснилось, для определения конкретной причины ошибки типа исключения (вкупе с местом его возникновения) оказалось недостаточно, а "шибко умные" аналитики/проектировщики из MS отказались от использования числового кода ошибки для идентификации конкретной её причины, ничего не остается делать, как анализировать текст сообщения об ошибке — со всем прилагающимся к этому геморроем.

Это был я

Еще вдогонку к написанному:

В случае "недопустимого имени" текст об ошибке такой (привожу его полностью):

"Имя файла или папки содержит недопустимые знаки. Используйте другое имя.<nativehr>0x81020073</nativehr><nativestack></nativestack>"

Угадайте, какое значение принимает защищенное свойство HResult (недоступное мне, смотрел под отладчиком)? Правильно, 0x81020073. Но только "добраться" до него я не могу. Ибо оно — защищенное. Мне придется "вытаскивать" его из сообщения об ошибке. Нет слов. Может, есть какой-нибудь грязный хак? Наподобие reinterpret_cast<> в плюсах?

Здравствуйте, teapot2, Вы писали:

T>Угадайте, какое значение принимает защищенное свойство HResult (недоступное мне, смотрел под отладчиком)? Правильно, 0x81020073. Но только "добраться" до него я не могу. Ибо оно — защищенное. Мне придется "вытаскивать" его из сообщения об ошибке. Нет слов. Может, есть какой-нибудь грязный хак? Наподобие reinterpret_cast<> в плюсах?

SPexception.ErrorCode.
Учите мат.часть!

Здравствуйте, Аноним, Вы писали:

А>Я просто обязан на это закладываться. Я не знаю, как это получается — мне ни разу не удалось отправить сообщение с одним и тем же дважды вложенным файлом, мой почтовый клиент это не разрешает.
Мой — разрешает.
А>Но клиентам это как-то удается, значит, мы обязаны этот случай обработать. Добро пожаловать в реальную жизнь. Предлагаемый Вами способ — не что иное, как дублирование уже реализованной системной функциональности в своем (пользовательском) коде.
Да. А ещё некоторые при вычислении среднего проверяют, что коллекция имеет ненулевую длину, перед тем как выполнять деление. Хотя эта функциональность встроена ажно в железо.

А>Со всеми вытекающими. Где гарантия, что результаты моего поиска будут идентичными встроенному? Это не так очевидно, если принять во внимание различные аспекты типа чувствительности к регистру букв и т.д.. Именно поэтому я не буду так делать.
Эта гарантия гораздо надёжнее, чем гарантия корректного парсинга текста. Завтра придёт микроапдейт к шарепоинту, и ваш код перестанет работать.

А>Тем более, что совершенно не исключено, что в будущих версиях фреймворка это будет вполне допустимо.
Ну и что. Такое изменение не сделает ваш код некорректным.
А>Аналогично предыдущему. Встроенные системные алгоритмы подвержены непредсказуемому изменению. Недопустимые сегодня варианты могут стать допустимыми завтра.
И тем не менее вам это никак не помешает.

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

T>>> а для файлов с запрещенными расширениями — отказать в приеме и отправить уведомление типа "Файл xxx.asa не принят, так как файлы с расширением asa запрещены к приему администратором сайта".
S>>Вот тут уже имеет смысл выделять полученное исключение программным способом. Может быть, для этого есть специфический код ошибки?
А>Удивительно, что вы не предлагаете это тоже проверять в пользовательском коде. Именно этот случай — наиболее простой для пользовательской реализации, так как список запрещенных расширений файлов можно получить вызовом системной функции. Но, опять же, зачем эту проверку делать мне в своем коде, если уже прекрасно делает за меня система?
Например, затем, что система делает это недостаточно хорошо.
Повторю вопрос: а код ошибки шарепоинт в SPException не заполняет?
А>Кратко подведу итоги темы:
А>Поскольку, как выяснилось, для определения конкретной причины ошибки типа исключения (вкупе с местом его возникновения) оказалось недостаточно, а "шибко умные" аналитики/проектировщики из MS отказались от использования числового кода ошибки для идентификации конкретной её причины, ничего не остается делать, как анализировать текст сообщения об ошибке — со всем прилагающимся к этому геморроем.
Вы странный. Вы смотрите на один конкретный пример, далеко не самой хорошей библиотеки, и делаете из него выводы космического масштаба. Проблема — не в исключениях, а в шарепоинте.