What is the best way to implement sequential error handling?

Question

PHP

I have a general question here ..
There is a class that implements some low-level operations (for example, PDO). When an error occurs, it throws some of its exception.
There is a higher-level class (for example, User) that uses the class described above internally. This class also has its own exceptions.
Question: does it make sense to intercept low-level class exceptions (PDOException) and throw out higher-level exceptions (UserException)?
All this might look like this:

<?php
class User
{
  function doSomething()
  {
    try
    {
      // запрос к базе с ошибкой
    }
    catch (PDOException $e)
    {
      // операции, выполняемые в случае ошибки
      throw new UserException('описание ошибки');
    }
  }
}

Often, operations with a low-level class somehow have to be wrapped in a try-catch, because in case of an error, some additional operations must be performed.
Moreover, using a class constructed in this way, we know in advance which exeption it can return (for example, the User class returns only UserException, and will never return PDOException).
But there are also drawbacks - as a result, we end up with a lot of sequentially executing try-catch blocks, when it was possible to do one try outside and many catch blocks for each type of exceptions (if necessary). In addition, in addition to PDOExeption, ErrorExeption can occur..
And another moment - the transfer of information about the error to the user. Let's say User::getUserByEmail('abc') will return a UserException "Email is not valid" - how best to process it in order to give the user understandable information about the error? Store an array of matches errorCode => errorMessage, where errorMessage is a clear description of the error in Russian?
Interested in how you solve such issues and why?

Answer 1

An extra try-catch is always an increase in load. Therefore, where there are wrappers for the sake of wrappers, it is better to remove them. Some projects manage with several common classes for errors, not by origin (you will see this in the trace), but by purpose: ClientException, AppExcetion and CoreException.
If you have noticed, then exception inheritance has not received wide distribution.
Now I'm thinking about a model similar to the event model in js. First of all, I classify events by type, not by source class, instead of a numeric ID (which, again, is almostno one uses), I use a text id like `user_login_failed` and an array $data with data. Thus, I always see what the error came from, I get the data in a convenient form: the $data array is iterated and available programmatically, I easily translate the error into a message in the desired language (RU, EN) with data substitution from the data object, transfer it to other sources , for example over the network. Such data can be put in the database at least :)