Как называется такой паттерн обработки исключений?

Question

[romaro]

Паттерн, при котором исполняемый код оборачивается в try...catch на самом верхнем уровне и определяется несколько наследников от базового класса ошибки, логика обработки которых прописывается один раз в корневом catch:

class FormError extends Error {};
class AuthError extends Error {};

function auth() {
  // do something
  throw AuthError;
}

function validator() {
  // do something
  throw FormError; 
}

try {
  auth();
  validator();
} catch(err) {
  if (err instanceof FormError) {}
  if (err instanceof AuthError) {}
  // unhandle err
}

Comments

[キム ファイブプラス]

Чего? Какой паттерн? Обычное наследование.

[Егор Тельнов]

Это называется ООП с:

Answer 1

[Василий Банников]

Никакого названия у такого паттерна нет.

В целом это то, как обычно идёт обработка исключений в C# и Java.

Comments

[mkone112]

И в питоне, да и наверное много где.

[Василий Банников]

mkone112, везде где исключения нормальные, а не как в жс, что можно что угодно в throw засунуть.

[romaro]

Василий Банников, в C# исключением может быть только объект ошибки?
Выглядит удобным, что JS допускает передать в catch-переменную "обычный" объект. Я так планирую обрабатывать инстансы класса Exception, которые создаются для "управляемых" ошибок, т.е. ошибок в рамках бизнес-логики (например, FormException, когда пользователь ввел некорректные данные и форма оказалась невалидной). Для них не нужно генерировать стек вызовов, поэтому наследование от Error кажется лишним.

[Василий Банников]

romaro,

в C# исключением может быть только объект ошибки?

Не только в C#, но и во многих других языках, где есть обработка исключений, выкинуть можно только наследника какого-нибудь базового Exception.
Это нужно, чтобы были всякие стандартные для всех ошибок поля - Сообщение об ошибке и стек вызовов.
Вроде только в JS кинуть можно абсолютно любое значение.

Для них не нужно генерировать стек вызовов, поэтому наследование от Error кажется лишним.

Моё мнение - код, который выбрасывает исключения, и активно их ловит, читать сложно (в плане неочевидности переходов).
По тому их нужно выбрасывать только при действительно исключительных ситуациях.
И это даже не говоря о том, какие они ресурсоёмкие.

Некорректные данные в форме - вполне себе обычная ситуация, и её лучше обработать в основном флоу.
Советую посмотреть в сторону монадической обработки ошибок.

Answer 2

[Василий Дёмин]

Возможно так - pokemon exception handling

Answer 3

[maaGames]

Когда виртуальное поведение скрывается в невиртуальной функции, то это шаблон "шаблонная фукнция" (без полиморфизма тоже применимо). В данном случае "шаблонная фукнция" не только обработку исключений делает, но и обеспечивает вызов виртуальных функций auth и valid в правильном порядке.