How to design exception handling?

Hello! Now designing your framework. Previously written on yii2. Decided to implement exception handling in the core of the framework. Read this https://habrahabr.ru/post/30399/ and a few articles about exception handling. In practice, began to write exception classes and throw them in your code. Meanwhile when you install xdebug, we can see a nice call stack in the plate with the bug, the path to the file and line where the error occurred. When I throw custom exceptions, there is little that I need to write to write a catch block to handle it (otherwise thrown away and another error about not caught the exception - Uncaught exception), and a beautiful plaque with the stack disappears and it has to create itself (reinventing the wheel). What conclusion I did: if you throw somewhere an exception (Exception or some of their own), then under it I have to write a catch block, and invent a nice conclusion to re-stack, respectively if I have 20 of my custom exception, I have to write 20 catch blocks (if my goal is to output a unique error message and stack functions, this is not rational). And if not, throw an exception, it is a mistake I still make, in a beautiful frame. I got the impression that exception handling is beneficial only when you really need to write some handler (not just output the error message and stack). Then what is the benefit of using exceptions in the framework, what are Your thoughts?

Please do not prideratsya the words and point out errors in my reasoning, if they are, thank you.
July 2nd 19 at 13:56
2 answers
July 2nd 19 at 13:58
Solution
Most likely, You have a common entry point, wrap all of the code calling the application in try-catch there and catch \Exception. All custom exceptions must inherit from it to get this unit.

<?php
// index.php
try {
 $app = new \Framework\App();
$app--->run();
} catch (\Exception $e) {
 // handle any unhandled exception here
}
Thank you for your answer. Yeah, that's what I'm doing, but my question is, in which case exception would be appropriate, because they can perfectly track the error stack and see the error message, if there is one (by using xdebug). Even was such an option in this article https://habrahabr.ru/post/30399/that all errors to be handled via exceptions. So I'd like to hear Your opinion about the appropriateness of their use. Thank you. - eleanore_Runolfsson commented on July 2nd 19 at 14:01
Article detail did not penetrate, but, as I understand it, the point is to convert errors to exceptions.
Exceptions are needed, rather not in order to trace and see the error message, and in order for this error to properly handle. Thus to convert errors to exceptions, in my opinion, quite reasonable. A simplified example:

<?php
// index.php
try {
 $app = new \Framework\App();
$app--->run();
} catch (\Framework\AccessException) {
 $status = 403;
 $message = 'Forbidden';
} catch (\Framework\ValidationException) {
 $status = 400;
 $message = 'Bad request';
} catch (\Exception $e) {
 $status = 500;
 $message = 'Internal server error';
}
- Maryam.Kub56 commented on July 2nd 19 at 14:04
July 2nd 19 at 14:00
To catch the specific error makes sense if you expect it and know how to handle it. Otherwise, she falls to the top of the catch, there is logged and sent you a mail/message in the chat.
Next you have to decide what to do to correct the error, or it will be an expected exception and you'll add a catch handler.

Find more questions by tags PHPYiiExceptionsDesigning softwareOOP