Home >Backend Development >PHP Tutorial >When should we use exceptions?_PHP Tutorial
Let me digress first: I have done two things in the company that I think are very meaningful. The first is to set up a PHP email group, and the second is to set up a Hi group. Currently, both There are more than 500 phpers in it. I have always believed that building a communication platform so that students can communicate smoothly and simply is the basis and prerequisite for creating a positive technical learning atmosphere. So that everyone's problems will not become other people's problems. , is the most direct benefit. (Postscript: Many people have asked for the email group address. I’m really sorry. This email group is an internal email group of the company, and Hi is also an internal email group of the company. Thank you)
Yesterday, A colleague raised a question in the email group:
When should Exception be used in PHP? How does it perform?
This issue can be regarded as a classic issue that has been debated for a long time. Let me talk about my personal opinion.
What are the error codes (or status codes) corresponding to exceptions? Advantages, disadvantages, how should we use them?
Error code
First of all, the exception mechanism only appeared after the error code mechanism, so according to the theory of evolution, Exceptions naturally avoid some shortcomings of the error code mechanism. These shortcomings include.
1. The error information is not rich
function, which can only have one return value (of course , Lua can return multiple, but it is actually equivalent to returning an array in PHP). The most common function description we have seen is: return *** when successful, and return FALSE when error occurs. However, there may be reasons for a function error. There are many types of errors. A simple FALSE cannot tell the caller the specific error message.
So, we have seen some function descriptions like this: If the return value If it is greater than 0, it indicates a successful status code. If the return value is less than 0, it indicates an error status code.
However, this requires the function to return an integer (or number). For some other functions, we cannot It is judged by 0, >0, <0, and, even in this way, we still need to use the returned error code and some predefined macros (or call something like strerror()) to get a specific, readable Error message.
Therefore, some functions use global error codes and error messages to save specific error messages. At this time we see such a function description: Return *** successfully, error When it returns FALSE, the error code is stored in the global variable $errno (at least this is how most Linux library functions are described, haha).
Okey, this method can indeed work, but do you think, Is it ugly?
2. Adding an error status code may require changing the function signature
Suppose, you write a function, this function is very simple, very simple, you Thinking that it will never go wrong, you declare it as (using C language as an example, PHP has no return type hint):
<ol class="dp-c"><li class="alt"><span><span>void dummy() { </span></span></li><li><span>} </span></li></ol>
But then you slowly modified this function and gave it more function, this function may fail at this time. And you can't add an error return code to this function at all now.
Some people may say that PHP has no return value type restrictions, but think about the structure of PHP Functions and constructors have no return value. When an error occurs, if you do not use exceptions, I think you can only choose to die, or use the method in 2 to continue execution with the error.
In addition, In a good software system, the return type is actually a convention. When all functions used do not check the return value, you still cannot add an error return code to this function.
3. Error status codes may be ignored
What happens when one of your functions makes an error and returns an error status code, but the caller does not detect this return value? ? -_#. On the one hand, checking the return status code everywhere will cause the code to be very,ugly:
<ol class="dp-c"><li class="alt"><span><span><?php </span></span></li><li><span> </span><span class="keyword">if</span><span> (!call1()) { </span></li><li class="alt"><span> </span><span class="keyword">die</span><span>(); </span></li><li><span> } </span></li><li class="alt"><span> </span><span class="keyword">if</span><span> (call2() != SUCCESS) { </span></li><li><span> </span><span class="keyword">die</span><span>(); </span></li><li class="alt"><span> } </span></li><li><span> </span><span class="keyword">if</span><span> (call3() < 0) { </span></li><li class="alt"><span> </span><span class="vars">$msg</span><span> = error_get_last(); </span></li><li><span> </span><span class="keyword">die</span><span>(</span><span class="vars">$msg</span><span>[</span><span class="string">"message"</span><span>]); </span></li><li class="alt"><span> } </span></li></ol>
Exception mechanism
So now we Let’s take a look at the exception mechanism. If we use the exception mechanism, the above code can be written as:
<ol class="dp-c"><li class="alt"><span><span><?php </span></span></li><li><span>try { </span></li><li class="alt"><span> call1(); </span></li><li><span> call2(); </span></li><li class="alt"><span> call3(); </span></li><li><span>} catch (Exception </span><span class="vars">$e</span><span>) { </span></li><li class="alt"><span> </span><span class="keyword">die</span><span>(</span><span class="vars">$e</span><span>->getMessage()); </p> <li><span>} </span></li> <p> More conveniently, if your code is just the middle layer and your caller will be responsible for handling errors, you It can even be simply written: </p> <pre class="brush:php;toolbar:false"><ol class="dp-c"> <li class="alt"><span><span><?php </span></span></li> <li> <span class="keyword">function</span><span> myFunc() { </span> </li> <li class="alt"><span> call1(); </span></li> <li><span> call2(); </span></li> <li class="alt"><span> call3(); </span></li> <li><span>} </span></li> </ol>
And an exception object can contain richer error information, such as error message, error code, wrong number of lines, file, and even error context, etc. Avoid The shortcomings of "1. The error information is not rich".
We can also add exceptions to a function that returns void type without changing its function signature, so there will be no "2" mentioned above. Adding an error status code may require changing the function signature. For PHP, if the newly added error is not caught, don’t worry, it will obviously go wrong. The above mentioned "3. Error status" will not happen. code may be ignored".
However, there are also some voices against the use of exceptions:
1. Performance
As asked at the beginning of the article in: “How does it perform? ", the exception mechanism is indeed more expensive than the method of returning status code. For C++, when an exception occurs, stack unwinding also occurs.
Performance and convenience are often a contradiction. I It can only be said that you need to make trade-offs. If you are writing a small module, and its life cycle may be short, and it does not require any special design patterns, then I think you can do without exceptions.
而如果你在为一个庞大的软件做开发, 我想你更应该看重的, 应该是, 它的可扩展性, 可维护性.
2. 太多可能的Uncaught Exception
如果, 你调用了一个可能发生异常的函数, 但是却没有捕获这个异常, okey, Fatal Error了, 所以让我们的代码看起来:
<ol class="dp-c"> <li class="alt"><span><span><?php </span></span></li> <li><span>try { </span></li> <li class="alt"><span>} catch () { </span></li> <li><span>}.... </span></li> <li class="alt"><span> try { </span></li> <li><span>} catch () { </span></li> <li class="alt"><span>}.... </span></li> <li><span>try { </span></li> <li class="alt"><span>} catch () { </span></li> <li><span>} </span></li> </ol>
然而, 这个是可以经过良好设计避免的, 比如我在设计