How to properly organize exception levels and logging?

Question

PHP

I need to develop an integration system with various information systems.
During the development process, there will be cases where in unforeseen situations it is necessary to send notifications by mail, in other cases, write information to a log or send SMS in critical situations.
For logging and other notifications, I chose Monolog (just getting acquainted with the monologue).
The question is, how do I organize the work of Exception , so that there are different levels of exceptions and the corresponding actions are performed (writing logs to the log, etc.)?
I searched for information in different sources, found several articles on working with exceptions (an article on habr ).
UnloggedInterface- this interface marks exceptions that do not need to be logged at all.
PreloggedInterface - this interface marks the events that need to be logged in any case: it doesn't matter if they are processed or not.
OutableInterface - this interface marks the exceptions, the text of which can be displayed to the user: not every exception can be displayed to the user.
I don't understand what should be the inheritance hierarchy of Exception classes? How should Monolog (or any other logging system) be associated with exception classes?
Maybe you should use Monolog\ErrorHandler ? (but I don't know how) ..
Can you please tell me where can I see examples? Or where can I read more about it?
I would like to understand how it works. And look at examples of correct work with exceptions and logs.
You can even have examples on GitHub))
I would be grateful for any help.

Answer 1

The main mistake is to design exceptions taking into account how they will be used, the use of exceptions is the task of the application code, the application code may be different, it may change, for example
, the User Service UserService has a method for obtaining a user by id at the output of only UserEntity if for some reason there is no user, then throw UserNotFoundException
Now the application use cases:
1. For the rest api in the controller, we will make a request to receive the user and, having processed the exception, we will send a 404 response there, the absence of the user is not so critical.
2. There is a form for saving, for example, a product or an order, and you need to get information about the user by his session id, make a request but there is no user, handle the exception, for example, with a global application handler and log, give the user a notification of a failure, this is critical. 500 response