пары потенциальных ошибок нужны? Если да, то наверное будет неприятно почти в любом случае (по крайней мере, пока нету явного объединения типов)
Но если пачки ошибок, которые могут возникнуть одинаковые (что либо ты сваливаешься в одну конкретную, либо есть явные наборы ошибок, которые часто могут возникнуть в одном месте), то выстроить иерархию через sealed вполне легко (не обязательно её делать плоской, у тебя может быть условно самый общий Errors, более точные PriceErrors, IoErrors и тд)
Ок, пример: у меня есть sealed class Errors, есть его подтипы: IncorrectUserInfoError, IncorrectDeviceInfoError и так далее. Тут не организовать норм цепочку - либо обрабатывать всё (нет), либо else. Но else ветку не хочу - очень уж нравится, когда при добавлении новых наследников компилятор помогает мне найти места, где я забыл написать обработку.
Обсуждают сегодня