systematizing error codes for a web app in php?

I'm working on a class-based php web app. I have some places where objects are interacting, and I have certain situations where I'm using error codes to communicate to the end user -- typically when form values are missing or invalid. These are situations where exceptions are unwarranted ( and I'm not sure I could avoid the situations with exceptions anyways).

In one object, I have some 20 code numbers, each of which correspond to a user-facing message, and a admin/developer-facing message, so both parties know what's going on. Now that I've worked over the code several times, I find that it's difficult to quickly figure out what code numbers in the series I've already used, so I accidentally create 开发者_StackOverflowconflicting code numbers. For instance, I just did that today with 12, 13, 14 and 15.

How can I better organize this so I don't create conflicting error codes? Should I create one singleton class, errorCodes, that has a master list of all error codes for all classes, systematizing them across the whole web app? Or should each object have its own set of error codes, when appropriate, and I just keep a list in the commentary of the object, to use and update that as I go along?

---

Edit: So I'm liking the suggestions to use constants or named constants within the class. That gives me a single place where I programatically define and keep track of error codes and their messages.

The next question: what kind of interface do I provide to the outside world for this class' error codes and messages? Do I do something like triggerError(20) in the class, and then provide a public method to return the error code, the string constant, and the user- and admin-facing message?

---

You could create a couple of defines to create named constants for all your error codes :

define('ERROR_CODE_SQL_QUERY', 1);
define('ERROR_CODE_PAGE_NOT_FOUND', 2);
define('ERROR_CODE_NOT_ALLOWED', 3);
// and so on

And, then, use the constants in your code :

if ($errorCode == ERROR_CODE_SQL_QUERY) {
    // deal with SQL errors
}

With that, nowhere in your code you'll use the numerical value : everywhere (except in the on and only file where you put the defines), you'll use the codes.

It means :

• Less risk of errors, as all numerical values are set in only one file
• Less risk of errors, as you'll use the constants, that have a name which indicates what it means
• And code that's easier to read.

Another idea could be to create a class to deal with errors :

class Error {
    const CODE_SQL_QUERY = 1;
    const CODE_PAGE_NOT_FOUND = 2;
    const CODE_NOT_ALLOWED = 3;

    // Add some methods here, if needed
}

And, then, use something like this :

if ($errorCode == Error::CODE_SQL_QUERY) {
    // deal with SQL errors
}

Which one is the best ?

It's probably a matter of personnal preferences... If you need to add some methods to deal with the errors, using a class might be useful. Else, defines are a great solution too.

---

At the very least, can you bump the code numbers up to be class constants or members?

class MyErrorProneClass { 
    const TURNED_INTO_A_NEWT = 12;
    ...

    public function dontBurnMe() {
        // echo your error here using self::TURNED_INTO_A_NEWT
}

This way you can manage the errors in the same place where you use them, rather than having to maintenance a large central file. I tried something to that effect in the past and it becomes difficult to keep up.

Generating error numbers programmatically may be a better long-term solution. If you could use information about the file or line number (__FILE__ and __LINE__ respectively), that would help.

Hope that moves in the right direction at least.

Thanks, Joe

---

Edit:

A class member would follow this syntax instead:

class MyErrorProneClass { 
    protected static $turnedIntoANewt = 12;
    ...

    public function dontBurnMe() {
        // echo your error here using self::$turnedIntoANewt
}

Since constants are public by default, you can access them from other classes directly if you want. So, from the outside, the error would be referenced as:

MyErrorProneClass::TURNED_INTO_A_NEWT

For associating to messages, you would use a mapping (either in a database, or in some localization file) from error ID (and frontend/backend) to displayed string. This use of keys for messages isn't optimal, but it would allow you to change error messages without changing code as well.

---

If you don't know already it might be an idea to use trigger_error (), plus an error handler if you want to present the user with a better error message.

---

Have you thought about using exceptions? They may be a good choice for your problem here although adding them to your project now would probably require some restructuring.

You can extend the basic exception class so it fits your problem in terms the of user / developer error message separation.