Question

We have a standard in use, where we create exceptions within the main class for returning errors etc… The problem is, that all the standard sniffs do not like this. We are writing our own sniffs then for this, but thought I would inquire why this was not desirable?

For instance, we have:

<?php
class FOO_EXCEPTION extends Exception   {   }
class FOO_EXCEPTION_BAR extends FOO_EXCEPTION   {   }
class FOO_EXCEPTION_POLE extends FOO_EXCEPTION  {   }

class FOO
{
    public function MethodDoingSomething()
    {
        if('some condition happens')    {
            throw new FOO_EXCEPTION_BAR();
        }

        if('some other condition')  {
            throw new FOO_EXCEPTION_POLE();
        }
        ...
    }
}
?>

This allows our code to return different exceptions to indicate what happened to the caller, but if a dedicated try/catch is not available, the basic Exception may still be caught.

This comes in handy when working with databases or other external objects, since the nature of the error may be returned to a component higher up the call stack to handle the error.

For instance, if you are deleting a file, and the file does not exist, the code may throw the exception, but the caller has the option to ignore this if it was not concerned that the file did not exist, since it was trying to delete it anyhow. However, another caller, could error out with the absence of a file that was suppose to exist when it was being deleted.

Answer 1

In my opinion, the coding standard which you describe in your question is perfectly reasonable. And I think for the purposes of your project it would be better to tweak the “standard multiple classes per file” sniff so that it works with your code in this particular (special) case rather than waste your time tweaking your codebase to comply with “the letter of the law” for this particular sniff.

I agree with the assertion that it is better in general to avoid putting multiple class definitions in a single file. But every argument I’ve read (so far) for moving each and every Exception-derived class into its own separate file strikes me as an exhortation to “improve” code by making it less readable. As a human, I gain no maintainability benefit from cluttering my code with files containing a single line, each.

It’s true that it is easier to write an autoloader, for example, if each class lives in its own file. And if you’re generating/compiling your PHP code from some sort of meta-language then it costs you nothing to add extra levels to your directory structure. But I reject the conclusion that this way of organizing the code actually improves it in any useful-to-humans way.

EDIT:
For the record, I can see that it would be a good idea to move the definition of an Exception-derived class into its own file if it actually contains some “testable” logic. In such cases you might need to mock/stub the class when writing automated tests for the logic which uses the class, which would require you to be able to load the class definition separately from the logic which uses it. But this not the situation described in the original question, where the Exception-derived classes are all “empty”.