Dev Easy Notes

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

Я говорю про кейсы вроде валидации, логики расчета цены и подобные штуки. Вот это места, где исключения плохая идея. Есть две основные причины почему так не стоит делать.

Во-первых, они довольно дорогие по памяти и по скорости. Каждый раз когда вы создаете исключение, в момент создания собирается stack trace всех вызовов функций потока до самого метода run. Функция сбора stack trace нативная, а jni не супер быстрый механизм. Помимо этого stack trace может много занимать по памяти.

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

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

Вызывая функцию мы ожидаем какой-либо результат. Когда функция бросает исключение мы заранее не знаем получим мы результат или флоу программы окажется в другом месте. Исключения очень похожи на метку goto в языке Си, и естественно строить логику на goto идея такая себе.

Суть проста, не делайте бизнес логику на исключениях. Бизнес логика должна быть по максимум состоять из чистых функций. Это то место из-за которого можно потенциально потерять деньги. Грязными могут быть ui слой, data слой, штуки связанные с DI, но бизнес логика должна быть чистой.

👍26❤1

www.tgoop.com/dev_easy_notes/80

1.58K viewsApr 16, 2022 at 08:36

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

Я говорю про кейсы вроде валидации, логики расчета цены и подобные штуки. Вот это места, где исключения плохая идея. Есть две основные причины почему так не стоит делать.

Во-первых, они довольно дорогие по памяти и по скорости. Каждый раз когда вы создаете исключение, в момент создания собирается stack trace всех вызовов функций потока до самого метода run. Функция сбора stack trace нативная, а jni не супер быстрый механизм. Помимо этого stack trace может много занимать по памяти.

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

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

Вызывая функцию мы ожидаем какой-либо результат. Когда функция бросает исключение мы заранее не знаем получим мы результат или флоу программы окажется в другом месте. Исключения очень похожи на метку goto в языке Си, и естественно строить логику на goto идея такая себе.

Суть проста, не делайте бизнес логику на исключениях. Бизнес логика должна быть по максимум состоять из чистых функций. Это то место из-за которого можно потенциально потерять деньги. Грязными могут быть ui слой, data слой, штуки связанные с DI, но бизнес логика должна быть чистой.

BY Dev Easy Notes