История изменений

Ты не понимаешь, о чём пишешь. С явными проверками тебе придётся проверять каждый раз, когда возвращаешься из функции, чтобы протащить ошибку от места появления до обработчика. И проверки будут выполняться всегда. С механизмом исключений в современном Си++ в нормальном потоке исполнения проверок не будет. Вместо этого при генерации исключения рантайм найдёт место обработки и пойдёт напрямую туда.

Зато если исключение выкинется и нам нужно его обрабатывать это в 200-300 раз медленнее чем подход с if. Поэтому и возникла концепция panic, которые исключения, но для которых специально взяли другое слово, чтобы программист даже не думал их обрабатывать(кроме логгирования). Если нужна обработка то это Result, Either и другие подходы на if…

Вообще Result и panics просто для разного, оба подхода нужны. Вот мне понравилась такая классификация:

Domain Errors. These are errors that are to be expected as part of the business process, and therefore must be included in the design of the domain. For example, an order that is rejected by billing, or an order than contains an invalid product code. The business will already have procedures in place to deal with this kind of thing, and so the code will need to reflect these processes. Domain errors are part of the domain, like anything else, and so should be incorporated into our domain modeling, discussed with domain experts, and documented in the type system if possible. Note that diagnostics are not needed – we are using Result as a glorified bool.

Panics. These are errors that leave the system in an unknown state, such as unhandleable system errors (e.g. “out of memory”) or errors caused by programmer oversight (e.g. “divide by zero,” “null reference”). Panics are best handled by abandoning the workflow and raising an exception which is then caught and logged at the highest appropriate level (e.g. the main function of the application or equivalent).

Infrastructure Errors. These are errors that are to be expected as part of the architecture, but are not part of any business process and are not included in the domain. For example, a network timeout, or an authentication failure. Sometimes handling these should be modeled as part of the domain, and sometimes they can be treated as panics. If in doubt, ask a domain expert!

В С необязательно переизобретать exceptions, можно использовать abort для panics. В раст тоже можно задать использовать abort, вместо exceptions для паники, хотя по умолчанию exeptions…

Ты не понимаешь, о чём пишешь. С явными проверками тебе придётся проверять каждый раз, когда возвращаешься из функции, чтобы протащить ошибку от места появления до обработчика. И проверки будут выполняться всегда. С механизмом исключений в современном Си++ в нормальном потоке исполнения проверок не будет. Вместо этого при генерации исключения рантайм найдёт место обработки и пойдёт напрямую туда.

Зато если исключение выкинется и нам нужно его обрабатывать это в 200-300 раз медленнее чем подход с if. Поэтому и возникла концепция panic, которые исключения, но для которых специально взяли другое слово, чтобы программист даже не думал их обрабатывать(кроме логгирования). Если нужна обработка то это Result, Either и другие подходы на if…

Вообще Result и panics просто для разного, оба подхода нужны. Вот мне понравилась такая классификация:

Domain Errors. These are errors that are to be expected as part of the business process, and therefore must be included in the design of the domain. For example, an order that is rejected by billing, or an order than contains an invalid product code. The business will already have procedures in place to deal with this kind of thing, and so the code will need to reflect these processes. Domain errors are part of the domain, like anything else, and so should be incorporated into our domain modeling, discussed with domain experts, and documented in the type system if possible. Note that diagnostics are not needed – we are using Result as a glorified bool.

Panics. These are errors that leave the system in an unknown state, such as unhandleable system errors (e.g. “out of memory”) or errors caused by programmer oversight (e.g. “divide by zero,” “null reference”). Panics are best handled by abandoning the workflow and raising an exception which is then caught and logged at the highest appropriate level (e.g. the main function of the application or equivalent).

Infrastructure Errors. These are errors that are to be expected as part of the architecture, but are not part of any business process and are not included in the domain. For example, a network timeout, or an authentication failure. Sometimes handling these should be modeled as part of the domain, and sometimes they can be treated as panics. If in doubt, ask a domain expert!