2015-09-18 2 views
5

У нас есть собственный API, написанный на C#, где многие из методов имеют возвращаемые значения, обычно bool или ints, которые иногда игнорируют вызывающие. Возвращаемые значения существуют по какой-либо причине, например, для указания проблемы или результата какого-либо рода, поэтому мы хотим побудить вызывающих пользователей фактически проверять результат, а не просто беспечно полагать, что метод работал должным образом, только чтобы все было плохо дальше по течению.Visual Studio - есть ли способ генерировать предупреждение, если возвращаемое значение не проверено?

Есть ли способ использовать компилятор Visual Studio для обеспечения проверки возвращаемых значений путем пометки вызовов с использованием предупреждения или ошибки, когда вызывающий абонент не может проверить возвращаемое значение не-void-метода?

+0

Вы можете сделать что-то супер немое и использовать параметры «out» во всем мире. –

+6

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

+0

Возможно, инструменты, такие как StyleCop или FxCop, могут помочь? Я не использовал их лично, но я предполагаю, что это может быть хорошим вариантом для этих двух. – jjczopek

ответ

4

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

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

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

+0

Не всегда лучше бросать исключение. Например, все методы .TryParse (int.TryParse()) не генерируют исключение, когда вход не может быть проанализирован для int. В большинстве случаев yoiu должен проверять, насколько синтаксический анализ был успешным, но в некоторых обстоятельствах это не так. например, когда значением по умолчанию для результата является значение, которое вам нужно, когда вход не может быть проанализирован. – Luc

+0

Использование TryParse имеет смысл, если у вас есть ожидание, что он может выйти из строя, и иметь план резервного копирования (например, значение по умолчанию) , Однако, если другие люди называют ваш код, и вы не хотите, чтобы ответственность за обработку недопустимого значения ввода, еще более полезно просто использовать Parse и дать исключение пузырькам до вызывающего. – SaxxonPike

2

Там уже есть компилятор предупреждение для этого, [MSDN] [1]

[1]: https://msdn.microsoft.com/en-us/library/ms182273.aspx есть вы используете FX в КС

+0

Это утверждает, что нужно проверять только объекты или HRESULT, поэтому, если вы вернете простой int, он не появится, он будет работать. –

+0

, в то время как это отвечает на вопрос пользователей, это не должно быть практика передачи кода вызова. Что-то плохое/неожиданное произошло. –