How to use exceptions

It is a pity if your study of the concept of exceptions ends up reading the relevant section of the official documentation for your language.

Having studied the syntax of the try {...} catch (Exception $ e) {...} construct, having learned about the possibility of creating your own exception classes, inheriting them from the Exception class and superficially realizing the power of the mechanism in your hands, then you can go one by one from two ways:

• Start using exceptions right there . Say, screw them to a system in which they were never used. Or pin them to a project in which the PLO does not smell. Or, worst of all, try to use them everywhere, especially where it is not necessary.
• Try to understand where to apply them, how to do it correctly, and why they are needed.

1. It is necessary to be able to clearly distinguish an exception from a common mistake in a program, for example: an incorrectly entered username or password is not an exceptional situation! This is a user error, not a program, and it can occur very often. On the other hand, the failure of the mysql_connect () function due to the inaccessibility of the database server is an exceptional situation, an exception must be thrown! More on this further.

2. Class methods should not catch exceptions thrown by other methods of the same class. The library should not know anything at all about what to do in the event of an exceptional situation in its methods, since, depending on the system where it is used, this behavior can vary greatly. Its cause is to generate an exception. For example, if the file required for the correct operation of your entire class does not exist, you should not deal with it. This is a matter of higher levels of the application.
')
On the other hand, you can easily intercept exceptions thrown by lower levels (if you want). If you do not want, they will be passed along the stack to the nearest catch {} (more precisely, to the catch {} corresponding to the nearest try {} ). Suppose you have a wrapper class for working with a database, with methods like connect () , query (), and so on. Of course, if you cannot connect to the server, you need to generate an exception in the connect () method.

However, neither the connect () method itself, nor even the query () method, which could call connect () automatically, should intercept it! This exception should be intercepted at the higher level, which works with the methods of this class, and there it should be decided to try to connect to another server, use a different type of data source, simply display an error, or pass the exception even higher (on different systems differently, let them decide what to do). I hope the idea is clear.

3. In a large application, you must use your own exception classes (inherited from the built-in Exception ). This allows you to build a hierarchy of error classes and separate them by importance, type, and so on. Suppose we have a class Application_Exception :

class Application_Exception extends Exception{...}
:

class Logic_Exception extends Application_Exception{...}
-- , , .

class Data_Access_Exception extends Application_Exception{...}
-- , , , - .

class Security_Exception extends Application_Exception{...}
-- , , ;)

All these types of errors should be handled differently, for example, you should not shout about security errors to the entire Internet, but in the event of a database server failure, you can display an intelligent apology apology (in general, taste and color).

4. To obtain the maximum amount of error information, use the capabilities of the built-in Exception class, do not reinvent the wheel! If the file name and the string where the exception was thrown is not enough, you can use the getTrace () and getPrevious () methods, which will certainly lay out the whole "picture" of what happened (for more details, see the documentation).

In this post I tried to set out the main theoretical points that I consider most important when using exceptions. The original is in my blog.
Good luck!