Is it correct to throw exceptions in business logic?

Question

PHP

Recently, I have met a lot of criticism about this approach, but still, how correct is it to lay exceptions for the business logic service method through variations of Exceptions

try{
   $order = $orderService->createOrderAndNotify($orderRequest);
   return $this->view("success",[
      "orderId" => $order->getId()
   ]);
}
catch(OrderValidationException $ex){
   $logger->warning("error valid order", $ex->getErrors());
   return $this->view("warning",[
       "errors" => $ex->getErrors()
   ]);
}
catch(OrderException $ex){
   $logger->error($ex->getMessage());
   return $this->view("error");
}

Order\Exceptions exception hierarchy

OrderException extends RuntimeException
OrderValidationException extends OrderException
OrderNotFound extends OrderException

I see advantages:
1. a specific method response, and not some specialized DTO that gives everything in the world
2. exception handling depending on the situation and application logic
3. testability and documentation (phpunit, docblock)
4. transfer of additional. data in exceptions

Answer 1

I consider this good practice. An exception is one in which the program does not run as expected. But, excuse me, I expect the order to pass validation. I expect the order to be successful. Therefore OrderValidationException, OrderException are exceptions. An exception is not, for example, a user canceling an order - it's stupid to throw an exception on a click on Cancel.
Exceptions go much deeper than just "exception". They help separate error handling into different levels of abstraction, and using different types of exceptions allows you to handle specific errors where they need to be handled (on the right layer). Exceptions are very helpful in localizing the error in the future, they allow you to get rid of the If .. else sheet, checks for null, false and other heresy. They, most often, make the code cleaner.
But it’s worth using them carefully, after all, it’s worth separating the exceptional situation and the completely normal, standard execution branch. So, if there are no orders - this is NOT an exception, here you can return null - it is acceptable (although some throw an exception here, because it is very tempting to bind an exception code to HTTP codes). And if you have an upload of documents, and the user tries to upload a file that is too large, then this is already an exception.

Answer 2

The answer to the question in the title is simple: an exception is thrown when the code fails to do the job it was designed to do. This is a simple rule common to programming in general, and business logic is no different in this sense from any other code.
I would separate validation and order creation.
For the validator, errors in the entered data are not an exceptional situation, but a completely regular one.
That is, you can check the validation result with a simple condition, without any exceptions.
On mature reflection, I still agree that the approach with throwing an exception during validation can be applied.
But the code inside catch(OrderException $ex){ is redundant. Logging the error and outputting a standard message to the client is what the centralized error handler should do , which should be present in the application anyway. That is, this code is clearly redundant here.

Answer 3

No, this is bad practice.
An exceptional situation is an exceptional one. This is a request error, no connection to the database or the absence of a record that we are sure should exist, etc. This is an event after which code operation is IMPOSSIBLE.
By wrapping business logic in exceptions, you sign in a crooked architecture. Validation is a separate layer that should not give any exceptions, it is a regular system mechanism that should give the correct answer to the client code that uses it.

Answer 4

maybe it will be interesting
https://github.com/adelf/acwa_book_ru/blob/master/...