Are exceptions in php really that useful?

Question

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 sh

Answer 1

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...

Answer 2

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

Answer 3

There is a finite capacity to most development processes - i.e. even where its possible to predict all possible circumstances that the code might run in (i.e. all possible combinations of inputs, all possible states for supporting systems like database, DNS, existing data etc) then its just not practical to deal with every scenario. Using exceptions allows you:

1. to bundle a series of operations into one entity for the purposes of determining success/ failure as a whole

2. handle multiple different modes of failures with a single bit of code

So yes - I'd say that exception handling is a useful practice - but not a substitute for handling the common failure modes specifically, intelligently and informatively (and typed exceptions are IMHO a complete oxymoron).

Answer 4

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.

Answer 5

Your question is not uncommon, whether/when to use exception is sometimes a philosophical decision and many experienced developers can't wrap their heads around it.

That being said, I've found that listing out the distinct properties of each way of handling error makes it easy to choose your preferred way:

Return code

• The caller can ignore it or forget to check it
• The caller usually needs more documentation reading before he can use it (does 0 mean success or failure?)
• Object destruction is not guaranteed -- it all depends on the caller to clean up properly

When to use: It's pretty obvious. Use return codes when you trust the caller (internal code or trivial errors which can be safely ignored).

Exceptions

• The caller cannot ignore it
• The caller can still suppress it if he wants (with an empty try/catch)
• Object destruction takes places properly -- most of the time

When to use: When you don't trust your caller as much (third party) or you really need to make sure your error code doesn't go ignored.

Die

• Cannot be ignored and cannot be suppressed

When to use: It's usually obvious enough. You need everything to stop immediately.

(In a PHP context, I don't think it makes much difference. The above suggestions should still apply.)

---

(Aside)

Usually it's tempting to just write out an error message when something bad happens (especially when the first programming language you learned is PHP :P). But if you really want to grok OOP, it's not a proper way to handle errors.

Every object or every function should ideally only perform one function. If one function writes error to the screen and does its own thing, it's difficult to later switch to a DatabaseErrorLogger or TextFileErrorLogger or etc. One approach would be to supply a logger to use (this is called Dependency Injection). Another way to do it is to use exception -- this way, the caller gets to choose which ErrorLogger to use.

Answer 6

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

catch (Exception $e)
{ print ($e->getMessage()); }