Перевертывание исключений хорошая практика?

Question

Как вы думаете, поймать Исключение и ретронирование это хорошая практика?

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

public PointExtend(double x, double y, int r, int g, int b) 
     : base(x, y) 
    { 
     try 
     { 
      var color = new Color(r, g, b); 
      Color = color;     
     } 
     catch (InvalidColorValueException) 
     { 
      throw; 
     } 
    } 

Resharper говорит, предложение поймать броска является излишним, я согласен, полагая, что я ничего не делаю с Exception, но бросить его снова и если бы я не было бы просачиваться UI в любом случае, но ISN» t этот код для программиста легче читать, так что если он создаст PointExtend, он будет знать, что код может бросить?

Answer 1

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

Answer 2

Бросок в коде выше бессмысленен, как вы говорите, все время выполнения будет просто повторять одно и то же исключение. Вы можете удалить try catch, и он будет работать одинаково.

Если вы сделали что-то с самим исключением, это повод его поймать, иначе пусть оно пузырится и дает пользователю значимое сообщение, регистрирует его в журнале ошибок и вас, а пользователю не просто дается глупость exception pop up :)

Answer 3

Если вы не выполняете какую-либо конкретную регистрацию или обработку исключений, вы можете удалить ее.

Если вы хотите программист знать о возможном исключении, задокументировать:

/// <summary> 
/// Creates a new instance of <code>PointExtend</code> 
/// </summary> 
/// <param name="x">...</param> 
/// <param name="y">...</param> 
/// <param name="r">...</param> 
/// <param name="g">...</param> 
/// <param name="b">...</param> 
/// <exception cref="InvalidColorValueException">Should the provided rgb values be out of range</exception> 
public PointExtend(double x, double y, int r, int g, int b) 
     : base(x, y) 
    {    
      var color = new Color(r, g, b); 
      Color = color;        
    } 

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

EDIT: Согласно комментарию @Philip Stuyck, хотя я и согласен, я также считаю, что мы не живем в идеальном мире. Проблема с тем, что вы рекомендуете, заключается в следующем:

• Что произойдет, если вам потребуется отправить запутанную версию вашей DLL? Это то, что обычно происходит, когда компании продают свои DLL. Вы действительно не можете заглянуть в код, и имена методов могут зайти только до сих пор.
• Большинство проектов, как правило, больше, чем просто несколько классов, и каждый раз, проходя через код, чтобы выяснить, что происходит, может потребоваться много времени и может заставить людей отказаться от использования вашего продукта. Проекты с открытым исходным кодом, на мой взгляд, являются ярким примером this.
• Наконец, и что еще более важно, на мой взгляд, единственный раздел, где вы говорите, что делает ваш код, находится в сводке (в случае, по крайней мере, для .NET). Комментарии и документация должны пролить свет на , почему был выбран выбранным подходом.

Answer 4

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

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

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

http://apdevblog.com/comments-in-code/

блог со ссылкой на Чистый кодекс Роберт С. Мартин

Существует целая глава в этой книге о комментариях, тех, кто считает что вам нужно комментировать лучше читать эту книгу.

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

Мой ответ здесь может вызвать довольно дебаты, вы свободны в своем собственном мнении по этому вопросу. (Роберт Мартин говорит то же самое ;-)) Но дело в том, что во многих случаях комментарий просто загромождает код и уменьшает читаемость. Комментарий забыт обновляться и, следовательно, больше не встроен с реальным кодом, ...

Альтернатива документированию всего заключается в том, чтобы написать хорошие модульные тесты. Читая код модульных тестов, если они хорошо написаны, вы получите зависание того, как предполагается использовать код. То есть, если вы пишете api для использования другими людьми.

Хорошо написанный код, который также хорошо накладывается, не должен быть свернут до каждого отдельного класса в системе. Если вам нужно это сделать, чтобы понять код, то вывод еще раз одинаков. Это плохой код.

Имена методов и имена переменных, имена классов идут очень далеко. Прочитав книгу чистого кода, я значительно изменил свой стиль кода.

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