Почему драйвер Sybase JDBC "ест" исключения?

Question

Я использую официальный драйвер Sybase JDBC для подключения к базе данных и вызова хранимой процедуры, создав CallableStatement, привязав к ней параметры и вызвав для нее функцию .execute ().

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

Наконец, я обнаружил, что использование .executeUpdate () вместо .execute () дает исключения, но у меня все еще осталось два вопроса:

1. Почему .execute () и .executeUpdate () ведут себя по-разному? Из документации SUN интерфейса видно, что они должны делать (почти) одно и то же ...
2. Всегда ли уместно заменять .execute () на .executeUpdate () при вызове хранимой процедуры? Должна ли хранимая процедура соответствовать некоторым конкретным требованиям, чтобы ее можно было вызывать с помощью .executeUpdate ()? (например, должен ли он иметь оператор update / delete / insert в качестве последнего шага?)

Обновление : я пробовал jTDS, и он ведет себя правильно (как в: он выдает исключение SQLEx в обоих случаях - с .execute () и с .executeUpdate ()). Однако из-за не зависящих от меня ограничений отключение драйвера на самом деле невозможно.

Также: меня не интересует результат, возвращаемый этой хранимой процедурой, это процедура типа вставки / обновления. Я только вставил бы, чтобы видеть (и быть в состоянии поймать / войти), если это терпит неудачу или нет. Еще одна вещь, которую я пробовал, - получать предупреждения от соединения после .execute (), но он тоже ничего не содержал.

Answer 1

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

Answer 2

не уверен, являются ли люди сибазы "сумасшедшими". Может быть.

С другой стороны, не синхронное получение результатов, если вы не активно проверяете код возврата вызываемого оператора, может иметь смысл с точки зрения производительности. Я еще не проверил это полностью, но есть простое решение вашей проблемы (ASE 15.5, jconn 7):

исключение будет срабатывать при извлечении параметра out из сохраненного процесса (по крайней мере, при вызове хранимых процедур):

    // one may force the error check by retrieving the return code!
    cs = conn.prepareCall("{ ? = call sp_nested_error @nNestLevels = 1 }");
    cs.registerOutParameter(1, Types.INTEGER);
    cs.execute();
    try {
        cs.getInt(1);
        fail();
    } catch(SQLException e) {
        assertTrue(e.getMessage().indexOf("some error") > -1);
    }

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

Answer 3

ничего не знаю о Sybase, но

executeUpdate возвращает больше информации, чем выполнить: количество вставленных / обновленных / удаленных строк

-> он может использоваться с UPDATE INSERT DELETE и операциями DML в соответствии с javadoc.

executeQuery возвращает ResultSet, это для операторов SELECT.