Это злоупотребление обработкой исключений?

Question

У меня есть этот метод, который может возвращать три разных ответа.

Сначала предполагалось, что он вернет только два, поэтому я возвращаю его тип логического типа

как:

public static boolean isLoteWaitingForImage()

И появилась некоторая бизнес-логика, которая может иметь другой результат, поэтому метод был изменен на

public static boolean isLoteWaitingForImage() throws ImageNotPendingException 

Если определенный select возвращает значение null, но одна строка возвращает true, если не null, я возвращаю false. Если от select не было получено ни одной строки, я throw и ImageNotPendingException произвожу, потому что это не относится к указанным фильтрам в предложении where.

---

Также подумал о том, чтобы сделать это таким образом, у меня есть этот новый класс с типами, которые являются допустимыми для возврата из метода isLoteWaitingForImage(), с 3 свойствами констант с именем:

public class LoteResponse {
    public static int VALID = 1;
    public static int INVALID = 2;
    public static int NO_IMAGE_PENDING = 3;
}

Итак, у меня будет этот новый метод:

public static int isLoteWaitingForImage() {

    return LoteResponse.VALID;
}

---

Имея это на столе, у меня есть два вопроса:

• Любая "другая" идея о том, как этого добиться?

• Какой метод лучше использовать?

Answer 1

Да, это выглядит как оскорбление для меня.

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

Мне кажется, что вам нужно перечисление.

public enum LoteResponseState
{
    Valid,
    Invalid,
    NoImagePending;
}

public static LoteResponseState getLoteState()
{
    ...
}

Answer 2

• Если вы ожидаете, что код, вызывающий isLoteWaitingForImage(), будет непосредственно отвечать за обработку условия «нет изображения в ожидании», а также других, то используйте множественные возвращаемые значения , но используйте перечисление, а не целые числа!
• Если условие «нет изображения в ожидании» не может быть эффективно обработано кодом непосредственного вызова и вместо этого обычно обрабатывается выше по стеку вызовов, тогда исключение является лучшим вариантом.

Answer 3

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

Если вы действительно хотите отслеживать ситуацию, по какой-либо причине отладки или разработки, вы можете вместо этого выбросить RuntimeException("why a runtime exception is thrown").Написание собственного исключения кажется слишком чрезмерным, если вы не делаете что-то конкретное с исключением.

Надеюсь, в этом есть смысл.:)

Answer 4

Я определенно согласен с тем, что перечисление является лучшим выбором.

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

Answer 5

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

Возвращение enum - это странная вещь, поскольку оно уменьшает инкапсуляцию, делегируя бизнес-детали и обработку вызывающей стороне. Таким образом, звонящий должен знать слишком много о Кейли.

Извините за мой плохой английский.