S>Давайте ближе к нашему примеру с переводом средств. Вы бы делали NotEnoughMoneyException или код возврата?

S>В guidelines не вижу нигде совета делать коды возврата для данного сценария, наоборот написано "DO NOT return error codes".

S>Перевод средств с пустого счета целиком аналогичен открытию несуществующего файла. Если при открытии несуществующего файла принято выбрасывать исключение, то почему при переводе с пустого счета нужно поступать иначе?

X DO NOT use exceptions for the normal flow of control, if possible.

Except for system failures and operations with potential race conditions, framework designers should design APIs so users can write code that does not throw exceptions. For example, you can provide a way to check preconditions before calling a member so users can write code that does not throw exceptions.

The member used to check preconditions of another member is often referred to as a tester, and the member that actually does the work is called a doer.

There are cases when the Tester-Doer Pattern can have an unacceptable performance overhead. In such cases, the so-called Try-Parse Pattern should be considered (see Exceptions and Performance for more information).

Видятся варианты.

1)
TransferValidationResult CanTransfer(int toAccount, decimal amount);
long Transfer(int toAccount, decimal amount); // бросает исключение при неуспехе

2)
bool TryTransfer(int toAccount, decimal amount, out TransferValidationResult transferValidationResult);

S>Давайте ближе к нашему примеру с переводом средств. Вы бы делали NotEnoughMoneyException или код возврата?

S>В guidelines не вижу нигде совета делать коды возврата для данного сценария, наоборот написано "DO NOT return error codes".

S>Перевод средств с пустого счета целиком аналогичен открытию несуществующего файла. Если при открытии несуществующего файла принято выбрасывать исключение, то почему при переводе с пустого счета нужно поступать иначе?

X DO NOT use exceptions for the normal flow of control, if possible.

Except for system failures and operations with potential race conditions, framework designers should design APIs so users can write code that does not throw exceptions. For example, you can provide a way to check preconditions before calling a member so users can write code that does not throw exceptions.

The member used to check preconditions of another member is often referred to as a tester, and the member that actually does the work is called a doer.

There are cases when the Tester-Doer Pattern can have an unacceptable performance overhead. In such cases, the so-called Try-Parse Pattern should be considered (see Exceptions and Performance for more information).

Видятся варианты.

1)
TransferValidationResult ValidateTransfer(int toAccount, decimal amount);
long Transfer(int toAccount, decimal amount); // бросает исключение при неуспехе

2)
bool TryTransfer(int toAccount, decimal amount, out TransferValidationResult transferValidationResult);