Да про то что пакет повредился и проверять надо такие операции по уму
Не знаю что там в данном конкретном случае не так, но если все клиенты
должны перепроверять буферы, то зачем в принципе нужен isc_info_end?
Мимо кассы. Верну я тебе isc_info_end через 3 километра от конца твоего
буфера, и шо ?
А ничего не будет - ты нам еще в нужном месте вернешь
isc_info_truncated. А потом на следующий isc_*_info запрос начнешь
возвращать следуююшую порцию :) и так до конца 3-го километра.
Лично я с Карлоса поддерживаю в том плане что он рассчитывает на то что
сервер всё вернёт правильно.
Да ! Давайте все забьём на обработку ошибок ! Всё будет работать быстро
и все тр-ции будут отвечать "42" на все запросы !
Сорри, но если ты не собираешься возвращать ни isc_info_end, ни
isc_info_truncated, то вполне нормально что в драйвере полетить
исключение. И в Java я ничего против ArrayIndexOutOfBoundsException не
имею. И виноват будет сервер, поскольку фигню ответил.
В этом случае:
1) CLR сам делает проверки границ массива
Какой молодец ! И шо с этого ? Твоему приложению станет легче, когда оно
свалится от выхода за границы массива ?
А приложению станет легче от request synchronization error или похожего
исключения? Что оно с ней будет делать?
2) Все ошибки со стороны сервера сразу вылазят
А где ты видишь ошибки со стороны сервера в данном случае ?
Я тут влез внутрь дискуссии, но как я понимаю, Карлос выделил буфер,
сказал тебе размер, а ты ему ни isc_info_end ни isc_info_truncated не
передаешь. Правильно?
Роман
