Способ автоматически увидеть, какие функции могут потенциально вернуть исключение в C # - PullRequest
Новая
       22

Способ автоматически увидеть, какие функции могут потенциально вернуть исключение в C #

6 голосов
/ 27 мая 2009

Нет ничего более расстраивающего, чем видеть, как ваш код вылетает в отладчике при исключении метода, и вы не пытались его поймать.

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

Есть ли у встроенной визуальной помощи какой-то скрытый параметр, чтобы закрасить эти функции определенным цветом?

спасибо

R

Ответы [ 13 ]

6 голосов
/ 27 мая 2009

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

5 голосов
/ 27 мая 2009

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

  1. Рассмотрим неявно генерируемые исключения, такие как StackOverflowException, которые могут быть выброшены в любое время из любого метода. Вы должны предположить, что любой метод в CLR может выдавать исключения этих типов
  2. Отражение и / или делегаты могут скрывать фактический код, вызываемый в конкретном методе, поэтому вы не можете проверить все возможные пути кода метода.
  3. Это потребует проверки IL и метаданных.
  4. В .Net не требуется документировать исключения, которые явно вызываются API
3 голосов
/ 27 мая 2009

Я думаю, что у Redgate есть инструмент для этого "Охотника за исключениями" Они взимают за это после суда.

http://www.red -gate.com / продукция / Exception_Hunter / index.htm

2 голосов
/ 27 мая 2009

Как уже говорили другие, я не уверен, найдете ли вы надежный способ сделать это в C #, поскольку не поддерживает проверенные исключения.

В некотором роде это напомнило мне об интервью с Андерсом Хейлсбергом, в котором обсуждалось " Проблема с проверенными исключениями ". Я не пытаюсь использовать проверенные исключения, но предлагаю прочитать объяснение Андерса, лежащее в основе дизайна исключений в C #, и предлагаемый способ обработки исключений: централизованная обработка исключений.

1 голос
/ 27 мая 2009

Как уже говорили другие, вы должны предполагать, что каждая строка кода может выдать исключение, если вы не доказали, что это не может. Лучший вопрос: «Что вы планируете делать с этим?»

В общем, вы не должны ловить никаких исключений вообще.

Конечно, все остальное является исключением из этого правила. Имеет смысл перехватить исключение, чтобы зарегистрировать его (если ваша среда не делает этого за вас, как это делает ASP.NET). Имеет смысл перехватить исключение, чтобы заменить его другим исключением, которое предоставляет более подробную информацию о контексте: 

public int GetConfiguredInteger(string name) {
    string s = null;
    try {
        s = GetStringFromConfigFile(name);
    }
    catch (IOException ex) {
        throw new Exception(String.Format(
            "Error in configuration file foo.config when processing {0}", name),
            ex);
    }
    return int.Parse(s);
}

Вызывающий не мог знать, что IOException было вызвано файлом конфигурации, если вы не сказали им. Обратите внимание также, как я игнорировал все исключения, не связанные с файловым вводом / выводом. В частности, обратите внимание, что int.Parse даже не находится внутри блока try / catch.

Существует небольшое количество других подобных исключений, но основная идея перехвата исключений такова: не делайте этого, если только это не будет хуже.

1 голос
/ 27 мая 2009

Любой код может потенциально вызвать исключение, это ваша работа, чтобы попытаться предвидеть это!

Существует ряд сторонних инструментов, которые могут помочь при поиске некоторых распространенных ошибок, например, fxcop, и инструменты, такие как рефакторинг, могут выдвигать предложения.

В настоящее время проделана определенная работа, которая может помочь вам найти потенциальные исключения. Посмотрите на PEX, который может помочь сгенерировать тесты для ваших функций: research.microsoft.com/en-us/projects/Pex/ (кажется, что ссылка не работает во время публикации)

Еще одна интересная область - это контракты кода (входит в .net 4 / доступна как spec #). Контракты кода позволяют писать заявления, которые определяют условия, которые должны быть выполнены. Это может быть до и после вызова вашей функции, и вы также можете объявить инварианты. Условием может быть что-то простое, например value! = Null. Эти условия затем анализируются во время компиляции и выполнения, чтобы проверить, не нарушают ли пути кода их.

1 голос
/ 27 мая 2009

Все непустые методы могут генерировать исключения в той или иной форме. Если вас беспокоят сгенерированные вами исключения, вы можете отобразить их из intellisense так же, как методы фреймворка через документацию XML, например: 

/// <summary>  
/// I seem to have written a method to do a thing.
/// </summary>  
/// <exception cref="System.Exception">An unfortunate failure.</exception>
public void DoSomething()
{
   /* ... */
}
1 голос
/ 27 мая 2009

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

1 голос
/ 27 мая 2009

Я думаю, что резарпер дает вам подсказки об исключениях. Но из-за того, что C # не поддерживает проверенные исключения, существует способ определить исключения. Возможно, инструменты анализа кода, такие как NDepend, поддерживают это.

0 голосов
/ 27 мая 2009

Охотник за исключениями, упомянутый несколькими людьми, - хороший инструмент, чтобы помочь с этим. Я не знаю, имеет ли он связь с комментарием <exception> XML-Doc, чтобы можно было принудительно документировать исключения, генерируемые кодом.

Страница:
...