Здравствуйте! подскажите, какие накладные расходы несут за собой такай метод Вот

есть функция я её вызываю через try()
внутри функции я вызваю ещё и ещё и ещё функции, ну то есть ухожу вглубь, и в итоге, получил результат - неудовлетворительный и тогда бросаю EXCEPT
типо такой быстрый выход из вереницы функций, а не возвращать их все через return
Типо вроде как и стэк держится в раскрученном виде и потом его обратно сворачивать при исключении, а вроде и все функции через ретёрн делать, неудобно,
Может кто пояснить за эту тему?

Всё понятно, не понятно в чём твой вопрос

это называется рекурсивный вызов

так делать норм? так и делают большие дяди?

какие накладные расходы несут за собой такай метод - какие-то накладные расходы несёт. Проблема в том, что альтернативы у тебя нет.

так делать нормально

нет, не норм, опиши алгоритм нормально, оставь рекурсию школьникам на егэ

там нет рекурсии, просто много функций уходящих вглубь, ну и челу лень как я уже говорил делать во всех функция return а просто бросает except

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

а разве это не пагубно влияет на производительность? Типо насколько хуже станет откомпилированный код?

Если ошибка - надо выбрасывать исключение.

человек говорит что он в рекурсивной функции выбрасывает исключение, чтобы вернуться из неё

Так в итоге ты значение возвращаешь или ошибку выкидываешь?

Так я же и говорю это не ошибка, как бы, ну то есть ошибка, результат получился плохой но как бы не stack overflow

ошибку бросаю, и на верхней функции ловлю, типо быстрый выход из вереницы функций

ты замерял быстроту? Или так, на шару?

Exceptions are not flow control!

я в чужом коде ковыряюсь, и вот увидел такой метод, хочу понять, он целесообразен или нет?

Нет.

нет, так поступать не правильно

а почему?

ответ не так прост, как мне кажется, этот код писал неглупый мужик

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

ну, видимо он просто верил что это быстро, но оно не быстро, потому что сделано не для этого

ну да, так можно было и GOTO ебануть

а всё из-за рекурсии, смотри до чего ты в итоге докатился, а в начале все выглядело вроде как нормально

где вы тут рекурсию увидели, я ни разу про неё не говорил?

"Вот есть функция я её вызываю через try() внутри функции я вызваю ещё и ещё и ещё функции"

ну не ёё же саму, а другие

ну разные ж функции - нет рекурсии.

а в чём тогда проблема, все функции что-то да возвращают, само свернётся после последней

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

std::option, да, проверять на валидность. Оно будет работать быстрее исключения

Бросай исключение. Критерий простой - приложение (код) может дальше работать ? Да - возвращай значение. Нет - кидай исключение.

Здравствуйте. Ну собственно в этом и есть механизм исключений. Раскручивание стека при срабатывании исключения - неотъемлемая часть механизма. Кроме того, многие считают хорошей практикой обрабатывать исключения на более высоком уровне вложенности вызова функций, по отношению к которому оно было выброшено. Да, поддержка самой способности выброса исключений несет дополнительные расходы. Именно поэтому и рекомендуется использовать ключевое слово noexcept по мере возможности.

Вроде бы))