Smart Exception

Recently, I was picking design patterns and simultaneously trying to remake one project into exits. From this cocktail was born a few thoughts that I want to share with the public.

I must say that for me an exception! = Error. Exception is just an exceptional situation, a deviation from the main branch of program execution. In this case, we will be interested only in exceptions, which can either be processed without interrupting the program, or require some action before the execution of the program is interrupted. We will be especially interested in cases when several specific exceptions may occur during the execution of a certain part of the code, depending on which you need to perform different, but strictly defined actions by this exception.

As a rule, exceptions are used as a kind of container containing information about the exceptional situation. One part of the code generates an exception by enclosing the event information in it, and the other part of the code catches the exception and trying to process it. This is the usual method of dealing with exceptions. But who said that this is all they can do?

Let's see.
')
Usually, exams are used as follows:

 class a { public function mytest() { try { code_which_throw_exception(); } catch(myExceptionType1 $e) { myException1Catcher(); } catch(myExceptionType2 $e) { myException1Catcher(); } ... } } 

But why, tell us, are our exceptions a “silent”, passive object? Let's give him a little more freedom! Once this is an object, it can encapsulate processing logic.

Let's add the catchException() method to our exceptions, in which we hide the logic myException1Catcher() and myException2Catcher() respectively. We can, for example, pass the calling object as a parameter to this method.

Then our code will turn into the following:

 class a { public function mytest() { try { code_witch_throw_exception(); } catch(myException $e) { $e->catchException($this); } } } 

As you can see, the code of the calling class has decreased slightly. Has he become better? It depends on situation.

When this method can be useful

If in some place of the system a sufficiently large number of exceptions of different types can be generated, then the method can be quite convenient.

Another situation in which this technique can be successfully applied is, if necessary, to run through a call chain and perform some action at each stage. Then in the catch block, you call a method to handle the exception and then throw it again.

What are the benefits of this method?

An object that handles an exception does not need to know its exact type, because all exceptions are handled the same way. For proper operation, interface compatibility is sufficient.

In turn, it is not necessary to know what kind of object it caught: having received a link to $this , it can call a sequence of methods of the object that caught it and, accordingly, also requires compatibility only at the interface level.

In addition, it becomes possible to save additional data inside the exception handler that will move with it and, for example, keep statistics or even change the algorithm of actions.