Исправление byko3y, (текущая версия) :
Технически да. Но пользователь библиотеки ведь не передаёт этот буфер в параметре, он вызывается из сериализатора. И в случае чего, исключение прилетает даже не из сериализатора а из функции записи буфера
Сериализация данных и запись их во внешнюю сущность — это разительно отличающиеся задачи. Примерно как модель данных и отображение — классическое model-view. Да, исключение прилетает от кода, который пишет буфер от сериализатора на диск, и который потому знает детали записи на диск, знает имя файла, знает тип этого файла, знает размер блока. Это всё не нужно знать сериализатору.
Встречаются. Сколько бы ни был диск, он всегда почти полностью занят. А ещё чаще встречается обрыв связи к сетевому диску и когда из-за этого программа вместо предложения повторить падает со стектрейсом, очень неприятно
Отключение сетевого диска может давать более весёлые последствия, чем просто «повторить операцию?». Например, если используются блокировки, то благодаря «прозрачности» NFS в случаях перезапуска сервера клиенты могут наблюдать плохо предсказуемые явления, вроде прилета SIGUSR1 из ниоткуда с отпусканием блокировки, из-за чего два пользователя могут начать писать в файл и данные в нём превратятся в винегрет. Конечно, какая-нибудь Java не допустит порчи данных, потому по умолчанию приложение «безопасно» упадет.
Универсальное решение здесь одно — перестать пытаться играть в прозрачные костыли и начать относиться к сетевому хранилищу как к сетевому хранилищу. Если ты потерял соединение с сервером, то вероятна ситуация, что либо сам сервер сбросил блокировку (из-за перезагрузки), либо это сделал вообще другой пользователь, потому что ему, видите ли, заблокировал неизвестный пользователь (что может свидетельствовать о любом варианте некорректного завершения работы пользователем). Корректный способ решить проблему — это при восстановлении подключения сравнить файл с исходным редактируемым файлом. Если они совпадают, то можно просто перезаписать содержимое. Если не совпадают, то нужно смотреть на изменения и сливать их. Короче говоря, как слияние в VCS.
А ты мне пишешь «Повторить, Игнорировать?» — гладко было на бумаге, да забыли про овраги. Повторить-игнорировать хорошо работает только на примитивных однозадачных системах без сети.
У тебя удивительная логика «если подпереть костыль вторым костылем, то получается уже не костыль, а Архитектура». Типа «нам не хватает лапшелогики на исключениях — давайте еще поверх этого произвольно прыгать по строкам кода через возобновления».
Не произвольно, а в точки, где продолжения захвачены. И исключения становятся костылём именно потому, что им начиная с си++ обрезали функциональность. В нормальной реализации как в лиспе это полноценная удобная функция
От того, что ты аккуратно обозначил целевые точки для произвольных прыжков, твоя goto-подобная лапша не перестала быть лапшой. Вся индустрия идет к структурному программированию, как обеспечивающему хорошую предсказуемость и тестируемость. Может быть, когда-то и лисп научится в структурное программирование.
Исходная версия byko3y, :
Технически да. Но пользователь библиотеки ведь не передаёт этот буфер в параметре, он вызывается из сериализатора. И в случае чего, исключение прилетает даже не из сериализатора а из функции записи буфера
Сериализация данных и запись их во внешнюю сущность — это разительно отличающиеся задачи. Примерно как модель данных и отображение — классическое model-view. Да, исключение прилетает от кода, который пишет буфер от сериализатора на диск, и который потому знает детали записи на диск, знает имя файла, знает тип этого файла, знает размер блока. Это всё не нужно знать сериализатору.
Встречаются. Сколько бы ни был диск, он всегда почти полностью занят. А ещё чаще встречается обрыв связи к сетевому диску и когда из-за этого программа вместо предложения повторить падает со стектрейсом, очень неприятно
Отключение сетевого диска может давать более весёлые последствия, чем просто «повторить операцию?». Например, если используются блокировки, то благодаря «прозрачности» NFS в случаях перезапуска сервера клиенты могут наблюдать плохо предсказуемые явления, вроде прилета SIGUSR1 из ниоткуда с отпусканием блокировки, из-за чего два пользователя могут начать писать в файл и данные в нём превратятся в винегрет. Конечно, какая-нибудь Java не допустит порчи данных, потому по умолчанию приложение «безопасно» упадет.
Универсальное решение здесь одно — перестать пытаться играть в прозрачные костыли и начать относиться к сетевому хранилищу как к сетевому хранилищу. Если ты потерял соединение с сервером, то вероятна ситуация, что либо сам сервер сбросил блокировку (из-за перезагрузки), либо это сделал вообще другой пользователь, потому что ему, видите ли, заблокировал неизвестный пользователь (что может свидетельствовать о любом варианте некорректного завершения работы пользователем). Корректный способ решить проблему — это при восстановлении подключения сравнить файл с исходным редактируемым файлом. Если они совпадают, то можно просто перезаписать содержимое. Если не совпадают, то нужно смотреть на изменения и сливать их. Короче говоря, как слияние в VCS.
А ты мне пишешь «Повторить, Игнорировать?» — гладко было на бумаге, да забыли про овраги. Повторить-игнорировать хорошо работает только на примитивных однозадачных системах без сети.