Это хорошее программирование, чтобы иметь возвращаемый тип исключения?

Я столкнулся со странной ситуацией во время варианта использования проекта: ESQL вызывает метод java, отправляет ему входной параметр String, который метод будет демаршировать, применяет некоторую логику, а затем сохраняет полезную информацию из немаршализованного объекта. Таким образом, метод должен либо вызвать JAXBException, либо использовать попытку try для обработки возможных исключений.

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

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

Например:

public Exception doStuffAndCheckForErorrs(String inString)
{
    if(inString.equals(null))
    {
       return new Exception("Your string is null");
    }
    else
    return null;
}

Но у меня просто ужасное чувство, что я так поступаю.

Я открыт для любых мыслей или других решений по этому поводу, особенно если есть способ обойти проблему подписи ESQL.

ОБНОВЛЕНИЕ:

Добавление ссылки о том, почему процедура ESQL не может вызвать java-метод с предложением throws в подписи.

Выдержка из этой ссылки в разделе оператора CREATE PROCEDURE:

"Любой метод Java, который вы хотите вызвать, должен иметь следующую базовую сигнатуру: public static (< 0 - N параметров>), где должен присутствовать в списке типов данных Java IN в таблице в сопоставлении типов данных ESQL и Java (исключая Тип ССЫЛКА (недопустимый в качестве возвращаемого значения) или тип данных Java void. Типы данных параметров также должны быть в таблице сопоставления типов данных ESQL-Java. Кроме того, метод Java не может иметь исключение бросает пункт в своей подписи."

Источник

6 ответов

Решение

Это не вопрос Java, а вопрос ESQL.

ESQL может справиться с исключениями Java, которые выбрасываются через JNI в код ESQL, вы должны получить ошибку BIP2917.

Сначала я думал, что это могло быть проблемой с распознавателем методов ESQL, но в IIB v9 мне удалось успешно вызвать следующий метод:

public static void sayHello() throws Exception{
  System.out.println("hello");
}

Это заставляет меня думать, что, возможно, вы ошиблись в определении внешней функции / процедуры ESQL?

Источник

Дело в том, что вы НЕ МОЖЕТЕ ОБЪЯВИТЬ, что будет выдано исключение; вы все равно можете выбросить RuntimeException - без добавления предложения throws.

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

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

Источник

Возврат Исключение "быстро и грязно". Он может быть очень мощным и полезным, но по возможности этого следует избегать.

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

Источник

Простой ответ на ваш вопрос:

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

Я понимаю, что вы не можете выбросить Exception, поэтому вы должны рассмотреть дело с другим подходом.

Булевский подход хорош, когда вы хотите проверить какую-то работу: хороший = верните истину, плохой = верните ложь.

Инкапсуляция значений в объекте подразумевается, когда вы хотите получить результаты работы: good = return new YourResultObject (val1, val2, ..., valx), bad = return null.

Источник

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

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

    public Enum ReturnCodes {
         SUCCESS,
         NULLSTRING,
         ...,
         OTHERERROR,
    }
Источник

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

Альтернативой будет выбрасывать RuntimeException или пользовательский подкласс. Это позволит вам оставить его вне сигнатуры метода.

Опять же, случай использования кажется странным.

Источник
Другие вопросы по тегам