Получил сегодня такой интересный эффект. Разбирательство показало, что добавился класс, которому не задан интерфейс Serializable. При этом сам он в явном виде в поток не пишется, а может оказаться в значении поля внутри другого класса, который имеет Serializable и пишется в поток.
Но самая главная пакость заключается в другом. На тестовых примерах такая ошибка вызывает java.io.NotSerializableException, но в данном конкретном случае этого почему-то не происходит. Оладка показала, что ObjectOutputStream обнаруживает проблемы, но вместо того чтобы тихо мирно вывалить эксепшн, пытается записать его в выходной поток (writeFatalException)! Немножко поразмыслив понял что это правильно - на другой стороне в процессе приема объекта вместо очередного поля обнаружится эксепшен и вывалится с ним, а иначе мы рискуем получить блокировку уже там (поскольку объект целиком никогда не прийдет.) В моем случа это не важно, но универсальность должна быть универсальной, хуже от этого быть не должно... Однако стало и по прежнему неясно, где же приключился затык.
Смотрим дальше... затык происходит при вызове slotDesc.invokeWriteObject(obj, this) , где obj это экземпляр NotSerializableException. Теоретически должен вызваться метод writeObject этого класса.
NotSerializableException и его родитель, ObjectStreamException, IOException, Exception нужного метода не содержат, обнаруживается он только в Throwable и тут мы снова возвращаемся к ObjectOutputStream, метод defaultWriteObject(). Все что я могу тут сказать - мы туда приходим и впадаем в ступор где-то на выводе состояния стека. Что там такого криминального обнаружилось я право не знаю. Отладка становится трудоемкой и слабоосмысленной без каких-нибудь специальных инструментов, которыми я не владею.
Комментариев нет:
Отправить комментарий