具体来说,“@有它的用途”：

Now one really should use the @ operator very sparingly,handling@H_404_11@ errors instead of suppressing them. But there are a small number of@H_404_11@ situations I can think of where one might need to suppress some PHP@H_404_11@ errors. Let me offer two examples :

• You could be using some large external library which has made use of the @,and so need to be able to ignore those errors as the author@H_404_11@ of the library intended,otherwise your program is going to trip up@H_404_11@ where it doesn’t need to. You could edit the library,but it might@H_404_11@ take a lot of time,and your changes would again have to be applied@H_404_11@ each time the author releases an update to the library.

• Another example might be when the fopen function is used to open an external URL,and the URL cannot be opened for one of many possible@H_404_11@ reasons. The function returns false to indicate a fail,which is@H_404_11@ great,but to quote the PHP manual,“an error of level E_WARNING is@H_404_11@ generated” too,not so great — it should really result in an exception@H_404_11@ being thrown instead,as this is an irregular situation,but one which@H_404_11@ should be expected.@H_404_11@ In this case one would like to be able to ignore@H_404_11@ the error,and continue with the program execution,explicitly@H_404_11@ responding in an appropriate way – exactly what exceptions are for!@H_404_11@ There is,however,a way to convert the error to an exception and so@H_404_11@ avoid using the @ in this situation. In your custom error handler@H_404_11@ (which is where we find ourselves in this post),throw an@H_404_11@ ErrorException – this then requires you to explicitly catch and handle@H_404_11@ it in the code that was using the @ before,which is a better way of handling errors.