Ответ 1
-
Исключения, как правило, подходят для вещей, где отказ не ожидается в качестве опции.
-
Логические значения возврата - это путь для вещей, где иногда может быть неудача.
Таким образом, в ваших примерах я бы сказал, что есть исключения.
При разработке ваших библиотек классов, Когда вы создаете метод, когда вы решаете выбросить исключение или возвращать логическое значение.
Например.
public class MathHelper
{
public int Divide(int x, int y)
{
if(y == 0)
{
throw new DivideByZeroException("Cannot Divide by Zero");
}
return x / y;
}
}
Это простой случай, но затем вы начинаете создавать более сложные методы.
Что вы предпочитаете?
public void Parse(TextReader reader, string delimeter)
{
if(reader == null)
{
throw new ArgumentNullException("The reader cannot be null");
}
if(String.IsNullOrEmpty(delimeter))
{
throw new ArgumentNullException("The delimeter cannot be null");
}
}
public bool Parse(TextReader reader, string delimeter)
{
if(reader == null)
{
logger.Error("Parse failed with null reader");
return false;
}
if(String.IsNullOrEmpty(delimeter))
{
logger.Error("Parse failed with null delimeter");
return false;
}
}
Исключения, как правило, подходят для вещей, где отказ не ожидается в качестве опции.
Логические значения возврата - это путь для вещей, где иногда может быть неудача.
Таким образом, в ваших примерах я бы сказал, что есть исключения.
В документации Java есть что сказать об стандартном способе проверки предварительных условий:
https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#preconditions
То есть, создайте исключение, если оно открыто, и используйте assert, если оно закрыто.
Мне нравится, как С# делает то, о чем вы просите в своем примере. Вы можете получить метод (int.Parse
), который возвращает целое число или генерирует ошибку. У вас также есть метод (int.TryParse
), который заполняет предоставленный аргумент by-reference с целым значением и возвращает логический код состояния. Таким образом, если вы хотите получить и исключение, вы это сделаете. Если вы хотите обработать встроенную строку с использованием условного выражения, это тоже опция.
В то время как принятый ответ - это хороший общий совет, есть некоторые случаи, когда я предпочитаю (проверять) исключения, даже если имеет смысл логический метод:
Различные типы (ожидаемых) сбоев, требующих различной обработки. Альтернативами являются коды состояния int, которые требуют соответствующих констант и перечислений кода состояния, которые могут быть немного лучше, но все еще нуждаются в явной проверке.
Распространение исключений. Иногда вы обнаруживаете ошибку на уровне модели, но можете обрабатывать ее только в представлении, которое находится в цепочке. Таким образом, вместо того чтобы заставить все функции возвращать логические значения и распространять возвращаемое значение, используйте поведение по умолчанию для исключений и перехватывайте их в самом верхнем слое.