Structuring exceptions. What do you specify as exception code?

Question

PHP

To my shame, I realized not so long ago that working with exceptions is a very capacious and rather complicated topic, which goes far beyond the simple try .. catch, and which, with the right approach, can greatly simplify writing code, tests, logging, and eliminating errors.
I've overridden the classes of all base and SPL exceptions in PHP to be able to separate my application's errors from those of third-party libraries. I created classes of my own, commonly used common exceptions of the form NegativeValueException, OutOfEnumException and the like, which are used in code in many places. Created classes of important, specific exceptions, such as InvalidProjectNameException , which are used only in one place in the code. Those. with the structure sort of like order and I can easily distinguish one error from another.
But 1 question remains: what to write in the exception code when I throw an exception? I have not been able to find any best practices on this subject. I know several possible scenarios, but it seems to me that they are all hacks
1. http status codes
In some cases, give codes 403, 404, etc. quite appropriate. But this method is more relevant for working with something "external". Those. if we are talking about the backend of a web application, then it would be appropriate to give, say, an error 500 outside for the frontend in case of some internal server errors, but the spread of such errors can be very large. A controller can throw a 500 error when handling exceptions thrown by a service layer, model, or repository. Those. many "inner" exceptions can fall under this outer code. These internal exceptions will be logged by themselves, but when a client contacts you with a complaint like "I got an error 500 here", then you need to look for the reason in the logs, filtering it by a variety of parameters.
2. Keep a codebook.
You can try to maintain something like documentation, forcing each exception class to have its own code. Or even for each specific case of throwing an exception, set your own code. This code can be thrown out, displaying it to the user. In this case, it will be very easy to identify the error from the words of the client, but maintaining such a reference book will turn into hell, in which it will be easy to get confused. Or I just don't know the right methods to do it
3. Codes are needed only to distinguish the situation in which the same exception is thrown.
For example, I have a method that takes 2 email addresses as arguments. Each one is validated and an InvalidEmailException is thrown if it fails. Those. one class method in different places can throw the same exception. This is not convenient to test, and in order to simplify testing when throwing an exception, we can set a number as a code for each, and in tests distinguish the exception thrown from checking 1 and 2 emails. This is the only normal use of codes that I see at the moment
4. Write the user ID to the exception code
I read about this somewhere, in my opinion even on Habré. But I think it's a terrible practice. The user ID can be pulled out not always and not everywhere (unless, of course, you follow the SOLID principles). Yes, and this task should be solved by the logger, not exception codes
Please share your experience, how do you handle exceptions and what do you indicate in the codes?
UPD: the question is not about logging and searching for a specific error in the logs. Sentry successfully copes with this. I'm asking about how someone uses codes in exceptions, and I just gave examples of how they can be used with their pros and cons

Answer 1

As for me, creating a codebook is a meaningless and hemorrhoid thing.
Why hemorrhoids - you yourself answered this question.
Why meaningless: Do you think that customers will contact technical support and immediately say an error code? in practice, this will not happen ... the client will simply say "I clicked the button and it stopped working", and the support staff will still have to clarify what and how it happened there. So the code won't change anything. In addition, at the beginning, the directory will be conscientiously maintained, and during operation, the client / boss will tell some programmer Vasya that they washed it down as a feature on the project for a quick one, he will do it, but he won’t enter data into the directory, because he needs this crap. Therefore, as it were, the relevance of the reference book is likely to suffer in practice.
Why codes at all? An error occurred - returned 500 status and a description of the problem, recorded detailed information in the log and that's it. The client contacted those. support - we looked at what kind of exception arose, looked at its stack-trace in the log and that's it. A well-formed log + search system on it solves all problems with support.

Answer 2

In this question, flies and cutlets are mixed. The question, it seems, is about some kind of "structuring of exceptions" (that is, you are waiting for a class hierarchy), but in fact the author is interested in the issue of interaction with users and error identification.
The main problem is what is the connection between the exception code and the unique error code that serves to identify a specific place in the logs? These are completely different entities that have nothing in common. The error handler should be involved in the generation of unique codes, neither to the exception codes, nor to the exceptions themselves, much less to their hierarchy, this is all irrelevant.

Answer 3

Understood, you are interested in what the code property in exceptions is for. Unfortunately, I have not been able to google for an exact description of why php added this property to the exception and for what purposes php suggests using it today.
But I think that's how it happened historically. PHP 3 introduced the very first tools for working with OOP. Not as powerful and functional as you see them today in PHP 5/7. Then the exception mechanism in php did not allow adding multiple catch blocks. It didn't make sense, since PHP didn't have the ability to type function arguments. Accordingly, the only way to distinguish one exception from another inside the catch block is to use the code property. Time has passed, typing has been added, multiple catch blocks have been added, but the code property has remained, like many other things in php. Using the code property hardly makes any sense at present.