А точно вызывающий контекст имеет достаточно информации, чтобы добавить к ошибке что-то полезное? Так бывает далеко не всегда. Особенно если код написан по всем канонам декомпозиции.
Концептуально исключения и возврат ошибок строятся на разных подходах.
Возврат исключений предполагает, что обработка будет в вызывающем коде, то есть максимально близко к месту возникновения. В этом случае не всегда понятно, что с ошибкой делать, и возникает соблазн протащить ошибку дальше, что приводит к развесистой информации об ошибках в сигнатуре, и хрупкость в рефакторинге или замене реализации.
Исключения позволяют отложить обработку до места, когда будет понятно, что с ними делать. Но проблема в том, что какие-то исключения могут провалиться до самого верха без обработки с непоправимыми для приложения последствиями.
У исключений проблемы производительности растут в основном из большого объёма раскрутки стека. В описанном сценарии следует обрабатывать исключения близко к точке их возникновения, как только становится понятно, что делать с исключениями.
Выглядит до боли знакомо... По сути шаблонизация на клиенте, только клиенты нативные для мобилок. Такое было в тренде сначала в конце нулевых, потом в середине десятых (под это даже маркетинговое имя придумали - вебдваноль). Ибо схожие проблемы решаются схожим образом.
Дальше должна быть проблема с поисковиками, чтобы давать выдачу подходящих внутренних страниц, и как следствие server side rendering и перераскладкой архитектуры под это дело.
Представим, что нам одновременно нужно, условно, объект HTTP клиента, и HTTP сервер. А ещё GRPC сервер. Чтобы они работали вместе. И их надо друг за дружкой сконфигурировать. Нейминг с With не решает проблему выбора подходящих конфигураций.
Билдер может формировать промежуточное внутреннее представление, из которого потом целиком собирается объект. Совсем не обязательно чтобы задачей билдера было изменение собираемого объекта.
Но в таком случае было бы неплохо иметь интерфейс билдера во fluent стиле.
Унаследоваться можно далеко не от всего, и далеко не всем можно сказать, что надо использовать унаследованную форму.
Например, речь о примитивных типах. Или строки, конструирующиеся из строковых литералов.
В тинке многие инструкции кодируются 2 байтами.
Если хватит SRAM и оставшейся сотни байт на палку - будет совсем огонь.
del
Поставить exception trap тоже не дармовая операция.
someCode() vs try{someCode();}catch(...) {} тоже может иметь значимые отличия, особенно если вызов someCode будет очень быстрым.
Питон просто настолько медленный, что оверхед исключений никак не влияет на общую производительность.
А когда оно всё же выстреливает, случается большой переполох.
Так же можно сказать что обрабатывающему ошибки из каждой дырки либо нечем заняться, либо некогда пилить фичи.
В C# такие исключения оборачиваются в единый AggregateException, а составляющие его уходят в коллекцию InnerExceptions.
А точно вызывающий контекст имеет достаточно информации, чтобы добавить к ошибке что-то полезное? Так бывает далеко не всегда. Особенно если код написан по всем канонам декомпозиции.
Да, ошибок.
Концептуально исключения и возврат ошибок строятся на разных подходах.
Возврат исключений предполагает, что обработка будет в вызывающем коде, то есть максимально близко к месту возникновения. В этом случае не всегда понятно, что с ошибкой делать, и возникает соблазн протащить ошибку дальше, что приводит к развесистой информации об ошибках в сигнатуре, и хрупкость в рефакторинге или замене реализации.
Исключения позволяют отложить обработку до места, когда будет понятно, что с ними делать. Но проблема в том, что какие-то исключения могут провалиться до самого верха без обработки с непоправимыми для приложения последствиями.
Как говорится, выбирайте из двух зол.
У исключений проблемы производительности растут в основном из большого объёма раскрутки стека. В описанном сценарии следует обрабатывать исключения близко к точке их возникновения, как только становится понятно, что делать с исключениями.
Спросите Java как сделать ещё хуже (спойлер: checked exceptions)
Выглядит до боли знакомо... По сути шаблонизация на клиенте, только клиенты нативные для мобилок. Такое было в тренде сначала в конце нулевых, потом в середине десятых (под это даже маркетинговое имя придумали - вебдваноль). Ибо схожие проблемы решаются схожим образом.
Дальше должна быть проблема с поисковиками, чтобы давать выдачу подходящих внутренних страниц, и как следствие server side rendering и перераскладкой архитектуры под это дело.
Представим, что нам одновременно нужно, условно, объект HTTP клиента, и HTTP сервер. А ещё GRPC сервер. Чтобы они работали вместе. И их надо друг за дружкой сконфигурировать. Нейминг с With не решает проблему выбора подходящих конфигураций.
А если мы пытаемся сконфигурировать несколько сущностей?
Очевидно, почитать документацию... Ой
Билдер может формировать промежуточное внутреннее представление, из которого потом целиком собирается объект. Совсем не обязательно чтобы задачей билдера было изменение собираемого объекта.
Но в таком случае было бы неплохо иметь интерфейс билдера во fluent стиле.
Проблема в том, чтобы тулинг позволил угадать, что ещё туда передать можно.