Throw an exception or return error/success codes? Is it an exception that the method cannot complete its task?

Question

PHP

Exceptions are the most obscure topic in programming for me (so far). Even reading a bunch of information did not help me get a clear idea of ​​\u200b\u200bhow to CORRECTLY use them.
Is it difficult to convey the essence of the question in the field "The essence of the question"? Therefore, you need to read everything below :)
Sorry for the many letters.
Let's say there is a method transferMoney($amount, User $recipient) and we consider that any user input is expected (even a string with letters). And it can be anything due to the fact that the user can send a request with any data in the body directly to the server, and incorrect data can be sent by an unfinished client application. You can check whether the amount parameter was sent to the server at all and whether it is a number somewhere above the transferMoney() method. But you can find out if the amount is correct in a good way only in the browser / GUI or in the Domain layer in the transferMoney () method itself. And since the user can bypass both the browser and the GUI, only transferMoney() can do this. In transferMoney(), you need to extract the data of the user (who sends money) from the database and check if he has such an amount. It turns out that there is one reason for failure in the transferMoney() method, but what if another reason is added, for example, the user is prohibited from temporarily transferring money? Thus, it turns out that in case of failure, it is necessary to return the reason for the failure from the method, there may already be two of these reasons, but at the same time they are quite expected if you look at the general context (we expect incorrect data). Since they are expected, throwing exceptions is not logical. In the event that there was one reason for failure, then one could simply return false. But since there are two of them, it turns out that you need to return error codes (or a success code in case of success) or return something like [false, $error] and [true, null] (I saw this in a very popular book about PHP , only there was a record from the database instead of null). But what if another reason is added, for example, the user is prohibited from temporarily sending money? Thus, it turns out that in case of failure, it is necessary to return the reason for the failure from the method, there may already be two of these reasons, but at the same time they are quite expected if you look at the general context (we expect incorrect data). Since they are expected, throwing exceptions is not logical. In the event that there was one reason for failure, then one could simply return false. But since there are two of them, it turns out that you need to return error codes (or a success code in case of success) or return something like [false, $error] and [true, null] (I saw this in a very popular book about PHP , only there was a record from the database instead of null). But what if another reason is added, for example, the user is prohibited from temporarily sending money? Thus, it turns out that in case of failure, it is necessary to return the reason for the failure from the method, there may already be two of these reasons, but at the same time they are quite expected if you look at the general context (we expect incorrect data). Since they are expected, throwing exceptions is not logical. In the event that there was one reason for failure, then one could simply return false. But since there are two of them, it turns out that you need to return error codes (or a success code in case of success) or return something like [false, $error] and [true, null] (I saw this in a very popular book about PHP , only there was a record from the database instead of null). that from the method in case of failure it is necessary to return the reason for the failure, there may already be two of these reasons, but at the same time they are quite expected if you look at the general context (we expect incorrect data). Since they are expected, throwing exceptions is not logical. In the event that there was one reason for failure, then one could simply return false. But since there are two of them, it turns out that you need to return error codes (or a success code in case of success) or return something like [false, $error] and [true, null] (I saw this in a very popular book about PHP , only there was a record from the database instead of null). that from the method in case of failure it is necessary to return the reason for the failure, there may already be two of these reasons, but at the same time they are quite expected if you look at the general context (we expect incorrect data). Since they are expected, throwing exceptions is not logical. In the event that there was one reason for failure, then one could simply return false. But since there are two of them, it turns out that you need to return error codes (or a success code in case of success) or return something like [false, $error] and [true, null] (I saw this in a very popular book about PHP , only there was a record from the database instead of null). In the event that there was one reason for failure, then one could simply return false. But since there are two of them, it turns out that you need to return error codes (or a success code in case of success) or return something like [false, $error] and [true, null] (I saw this in a very popular book about PHP , only there was a record from the database instead of null). In the event that there was one reason for failure, then one could simply return false. But since there are two of them, it turns out that you need to return error codes (or a success code in case of success) or return something like [false, $error] and [true, null] (I saw this in a very popular book about PHP , only there was a record from the database instead of null).
But there is another design approach (sort of): the transferMoney() method is part of the core of the application, and Clean Architecture clearly states that the core is the foundation around which the application is built. That is, if I understand correctly, then transferMoney() should not adapt to the layer above, it should not have any assumptions that the user will enter something correctly or incorrectly, he should just expect only valid data, if they are incorrect, then this is an exceptional situation. That is, transferMoney() will throw an exception that will be raised to the Controller, and based on which the Controller will send a 400 Bad Request and the reason for the failure. Am I thinking right? Or is the first approach to the problem better (first paragraph)?
I found this thought on the Internet: "A good rule of thumb is that if a method does not do what its name suggests, it should be considered a method-level failure, resulting in an exception".
I want to note that I have not yet encountered the need to implement such a method, I am now only interested in working with errors.

Answer 1

As long as you call one function and decide what to do with its response, you won't understand exceptions.
That's when you need to call a function that calls class methods that call methods of other classes - you will either paint all the walls for yourself with the types of errors that each of these methods can return, or you will understand how wonderful it is - just catch an exception, if that something went wrong, and do not bathe with what and where exactly.