Best way to handle errors

Question

I was hoping you guys could help me on this one: how to handle errors and what to return? What I do, most of time, is make my functions/methods return two possible values. The intended value in case of success and FALSE in case of failure. This way I can use:

if(function()) { ... } else { ... }

I don't like to use exceptions because, generally, they print something and interrupt the functioning flow of the application. Of course, I can make them to return something and show an alert with the error. But it's too much work. And I don't like Pokemon so much to try to catch them all. (Awsum topic, btw)

Another thing I'm concerned about is to code something "error-handling" driven. As we know, users can do almost anything to cause an unexpected situation, and to code expecting these errors is too tiring and frankly, is making me paranoid. XD

I apologize for any english mispelling(I don't write too often). Thank you for reading this question. :D

PS: I read about defensive programming and the other questions but they don't quite answer my doubt.

Answer 1

Maybe you won't find my answer useful because I'm not a php developer, anyway I will try to give you common hints as error handling debates are common in any programming language.

1) First try to avoid the actual need for error handling. This does mean try to code in a way that error conditions are few as possible. A simple example: it's common sense that trying to clear an empty collection should not raise an error.

2) Distinct what is a supported failure than an unsupported one. A supported failure is an error condition that you actually want to track and handle as part of the program logic. An unsupported failure would be an error condition that's actually a code error. For example: you are trying to lookup an element in a map and it's part of the logic of your program that the specific element should be there. There's no sense to add code to test if the element was there and raise an error if it wasn't: you made the assumption it was there.

After you have understood these two points, I'm pretty sure you'll understand why exceptions are so useful to produce cleaner and more efficient code. The trick is: make your code to raise as few exceptions as possible (again: distinct supported and unsupported error conditions to choose what exceptions are actually needed) and catch them only at the most external scope, where the user of your application interact with it and 1)should be warned, 2)should decide what to do. Programmatically catch an excpetion without user interaction is, most of the times, a bad thing because it makes the dev think that catching exceptions is efficient just like conditionally do something (if-then-else) when an error condition arise when this is not the case. Exceptions won't cause any overhead to your application until they are thrown.

Answer 2

Have you tried working with PHP's error logging tools? http://php.net/manual/en/book.errorfunc.php

You can then use things like error_log() to shoot your custom errors to whatever log file you want.

Answer 3

You should consider using Exceptions . They don't print anything if you don't want to. At least this would be a better separation of your actual code and error handling.

You are right, having a function return a value or return false on error is not the best style (yes I know that this is probably done a lot).

If you want to learn more about good coding practice, I suggest to read Clean Code by Robert Martin .