Are exceptions in php really that useful?

2019-03-19 16:56发布

3 days ago I started rewriting one of my scripts in OOP using classes as a practice after reading a lot about the advantages of using OOP.

Now I'm confused weather I should use exceptions or not. They seem to make my work harder and longer.

My application check if the data was sent through an Ajax request or not then uses that info through the script.

Check this example :

 /*
 * The older way
 */

if($ajaxEnabled) {
    $error = errorWrap('Ajax error');
} else {
    $error = errorWithBackLinkWrap('NoAjax error');
}

function doSomething() {
    if(empty($POST['name'])) {
            die($error);
    }
}

/* 
 * OOP way
 */

class someClass {
    private $_ajaxEnabled;

    public function doSomething() {
        try {
            if(!$this->_isDateValid()) {
                if($this->$_ajaxEnabled) {
                    throw new ajaxException('Ajax error');
                } else {
                    throw new noAjaxException('NOAjaxError');
                }
            }
        } catch(ajaxException $e) {
            echo $e->getErrorMessage();
        } catch(noAjaxException $e) {
            echo $e->getErrorMessage();
        }
    }
}

This code is only for demonstrating the problem, so I know there are some undefined functions in it :).

So before going oop, error handling was easier for me because I only had to echo the appropriate error.

Now using exceptions, in every function I have to check the type of connection first then write 2 catch functions for each thrown exception, which lead to a much larger code.

I'm really new to OOP in php so maybe there is a cleaner and a better way to do this, is there ?

9条回答
爷的心禁止访问
2楼-- · 2019-03-19 17:12

You shouldn't use exceptions when your code can handle the error gracefully using an if statement (like you did there on your example).

Exceptions are for situation that are well, exceptional. Unfortunately this is not very straightforward, so it's up to you, the programmer, to decide what is exceptional or not. I think a good rule of thumb is:

Avoid using exceptions to indicate conditions that can reasonably be expected as part of the typical functioning of the method.

From: http://www.codeproject.com/KB/dotnet/When_to_use_exceptions.aspx

查看更多
别忘想泡老子
3楼-- · 2019-03-19 17:15

If all you need is to display error message, why don't you use

catch (Exception $e)
{ print ($e->getMessage()); }
查看更多
混吃等死
4楼-- · 2019-03-19 17:15

Its a developers call.. not mandatory as kizzx2 told. But if you are writing up some util or library kind of class its always good to throw exception as this lib or util may be used by others in future.

查看更多
地球回转人心会变
5楼-- · 2019-03-19 17:16

Exceptions as an error handling mechanism are VERY different in concept and implementation than function return codes. You cannot/should not simply map one to the other. You should read and digest this article (and then a few more including this one*) before proceeding further.

If you're going to favor exceptions instead of return codes for error reporting/handling then the structure of your code should change significantly.

(*The CodeProject link is .NET-specific but there's little code ti digest. It's mostly a best-practices article easily applicable to any language.)

查看更多
你好瞎i
6楼-- · 2019-03-19 17:16

I personally hate exceptions. I don't work with them in my applications. I prefer functions returning (and expecting) defined status codes, and dealing with recoverable errors on that level.

In truly exceptional situations (like an unreachable database server, a file I/O error etc.) that are an immediate emergency, I tend to trigger and handle a fatal error. (Object shutdown will still take place, so any connections that need closing etc. will still be handled as long as they are placed in destructor functions.)

Third party libraries' exceptions I strive to catch as quickly as possible, and deal with them in my own way.

Joel Spolsky puts the reasons much better than I could in his notorious Exceptions essay.

Note that this is one view and one school of thought. There is a lot of brilliant software whose error handling is based entirely on exceptions, and that is perfectly fine. The key is consistence - either you make the design decision to use them, or you don't.

查看更多
Rolldiameter
7楼-- · 2019-03-19 17:18

If I understand how you're doing it, I think you're doing it wrong. Exceptions for not for errors. They are for exceptional circumstances. Errors can mean any number of things (for example, a user didn't enter a long enough user name on a registration form). That itself shouldn't be an exception. You could however use an exception to show that registration itself failed (Depending on the situation)...

And you don't need to have a try/catch block at every level. In fact, that's bad practice. Only catch exceptions if you either can handle the exception, or need to do something else before letting the exception continue. So, for example: If you are connecting to a remote set of websites, and the first one fails. You can catch the exception for that one, and retry with a second website. And keep going until you have no more left (at which point you'd throw another exception to indicate that no websites could be fetched). Another example would be if you're generating images. You have a method that does some computation while generating the image that throws an exception. You'll want to catch that exception so that you can "clean up" from the image process (to save memory, etc) and then re-throw it once you're done: catch (ImageSomethingException $e) { /* Clean up here */ throw $e; }...

The true power of exceptions is that it lets you handle the situations however you want (since the exception can just bubble up to the top of the program). But only catch exceptions where you know you can deal with them (or at least need to clean up). You should almost never do print $e->getMessage() inside of production code.

Personally, I have a default exception handler that I always install. Basically, if an exception is not caught, it will log that exception and then generate a 500 error page. That lets me focus on what exceptions I can deal with in code instead of trying to catch everything (which isn't usually a great idea)...

Good luck...

查看更多
登录 后发表回答