Каковы общие механизмы обработки ошибок для шаблона Observer?

Question

Я изучаю шаблоны проектирования, и одна вещь, которую я заметил почти во всех примерах реализации шаблона Observer, заключается в том, что в методах субъекта регистрировать / отменять регистрацию на самом деле нет обработки ошибок.Это заставило меня задуматься, как / если это будет сделано.

Как конкретно обрабатывать ошибки, будет зависеть от потребностей приложения, но каковы общие способы обработки ошибок такого рода?

Например,Я пытаюсь зарегистрировать Обозреватель, но регистрация не удалась.Эта ошибка просто происходит молча, и допустимо, что этот конкретный Наблюдатель просто не получит обновления?Субъект не является более мудрым, я думаю, и может продолжать уведомлять Наблюдателей о том, что DID успешно зарегистрирован.

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

Answer 1

Если регистрация Обозревателя не удалась, вам обязательно следует вызвать ошибку.Клиент вашего кода ожидает уведомления об изменениях в Субъекте, и он должен иметь возможность реагировать, когда он не может этого сделать.Но неспособность зарегистрировать одного наблюдателя не должна затрагивать как субъекта , так и других наблюдателей.На самом деле, вы можете даже иметь наблюдателя для неудачной регистрации наблюдателя событий - мета-наблюдателя; -).

Но гораздо более интересным аспектом является ИМХО то, что должно происходить, когда наблюдатель выдает исключениев рамках notify метода?Нужно ли вызывать остальных наблюдателей?Должен ли этот наблюдатель быть снят с регистрации?Кто несет ответственность за эту ошибку?И где с этим справиться?

Существует несколько других шаблонов проектирования, которые решают эту проблему.Вы можете использовать Decorator и обернуть каждого Обозревателя, отлавливающего исключения, выданные из notify, и проглатывающего их (эхем, логирование).Субъект даже не заметит, что нормально.Кроме того, другие Наблюдатели не будут прерваны, потому что исключение поймано достаточно рано.

Также рассмотрите Композитный, чтобы объединить все Наблюдатели в один, виртуальный один.Затем украсьте это в вышеупомянутом исключении, ловящем наблюдателя.Кажется похожим, но исключение, выброшенное одним наблюдателем, будет препятствовать дальнейшему вызову наблюдателя.Теперь вы даже можете формировать иерархии ...

Answer 2

Обработчики уведомлений от наблюдателей действительно никогда не должны пропускать исключения, потому что единственная сущность, которая обычно больше всего заинтересована в исключении, это наблюдатель, который его выбрасывает. Исключение обычно означает, по сути, «я не мог сделать то, что вы просили, потому что X». Наблюдаемый субъект обычно не заботится о том, что обработчики событий что-либо делают, поэтому, таким образом, не будет заботиться, если он не сделает этого. С другой стороны, если исключение означает, что инварианты класса субъекта больше не встречаются, то исключение, вероятно, является неизбежным злом.

Если из обработчика уведомлений выдается исключение, его следует рассматривать довольно серьезно (если это какая-то глупая вещь купола, которая не должна была попасть в обработчик, это должно быть серьезно исправлено). Обычный паттерн событий Microsoft, когда пропускаются все обработчики событий, следующие за первым, генерирующим исключение, очень плох. Гораздо лучшим подходом было бы запустить все обработчики событий, захватывать все исключения по мере их возникновения и добавлять их в список, а затем в конце, если список не пустой, генерировать исключение EventHandlerException, которое содержит список всех исключений, которые произошла при обработке события.