Стоимость потока с использованием исключения

Question

Представьте себе простое банковское приложение, в котором реализуется сценарий использования перевода средств. При написании операции трансфертного фонда у программиста / дизайнера есть два варианта

1. Напишите операцию, чтобы проверить, достаточно ли средств, или нет, и верните логическое значение, на основании которого будет осуществляться последующий вариант перевода средств. Это требует создания двух функций, а именно. checkSufficientFunds () и TransferFund ()

2. Напишите одну операцию, которая сама проверяет, достаточно ли средств или нет. Это создаст проверенное исключение, если нет достаточных средств, и вызывающий метод должен обработать это.

   Я понимаю, что это слишком упрощенный сценарий. Мой вопрос, теоретически, каковы последствия производительности (память и процессор) этих двух подходов? Как они сравниваются?

Answer 1

Разница в производительности в текущих JVM должна быть незначительной. Однако придерживайтесь правила, что исключения должны использоваться в исключительных ситуациях. Это нормальный поток, когда средств недостаточно, поэтому я бы использовал метод public boolean transferFund(), который возвращает true в случае успеха, и false в противном случае. Это предложение нарушает разделение команды / запроса , но я думаю, что все в порядке.

Answer 2

Если бы я занимался проверкой кода, и кто-то мотивировал выбор между использованием исключений и вызовов методов по соображениям производительности, я бы отказался от этого разработчика.Это учебный пример субоптимизации и пустая трата времени.Оптимизируйте, где это имеет значение и оказывает измеримое влияние.Не экономьте миллисекунды за счет качества и надежности кода.

Что касается этого случая - некоторым людям нравится использовать исключения в качестве механизма управления потоком.Я не.Исключения, на мой взгляд, используются для обозначения достижения неожиданного состояния.Часто это аналогично ошибке.Проверенные исключения подразумевают, что состояние является чем-то, что может быть восстановлено в рамках текущей транзакции или диалога.Непроверенное исключение означает, что надежного восстановления нет, и система должна предупредить пользователя.

Answer 3

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

С точки зрения производительности каждый раз, когда вы генерируете трассировку стека, которая потребляет память и время. Iirc делает путь выполнения в 70 раз дороже.

Answer 4

Во время выполнения блоки try-catch существенно не влияют на производительность.Только когда возникает исключение и в этих случаях вы все равно должны обработать исключение.Но вы должны использовать исключения только тогда, когда они требуются (когда приложение не может нормально предшествовать).

Answer 5

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

boolean transferred = transferFundsIfAvailable( ... );

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

if(checkSufficientFunds()) {
    // another thread transfers funds
    transferFund(); // but there is not enough any more
}

Также вы можете забыть сначала вызвать чек.Тебе лучше без него.