Should I throw PHP 7's Error classes in a library? [closed]

Question

I have open-sourced a math library for PHP, which defines its own hierarchy of exceptions:

• ArithmeticException
  • DivisionByZeroException
  • NumberFormatException
  • RoundingNecessaryException

Now that PHP 7 has landed, I realize that some exceptions feel a bit redundant with the new Error classes introduced:

• ArithmeticError
• DivisionByZeroError

Let's forget PHP 5 for a moment and assume that the library only targets PHP 7.

• Should I throw ArithmeticError and drop my ArithmeticException?
• Similarly, should I throw DivisionByZeroError and drop DivisionByZeroException?
• Should RoundingNecessaryException and NumberFormatException extend ArithmeticError?
• In this case, should they be called RoundingNecessaryError and NumberFormatError?

At first glance, it seems weird to redeclare exceptions that have a native equivalent in the language.

At the same time, and although nothing prevents userland code from throwing an Error, I feel like these classes were designed to be thrown by PHP itself, and that userland libraries are better off throwing Exception and not Error.

Is there a consensus on the subject?

Answer 1

You're going to have Stack Overflow moderatory literalists voting to close this because answers are going to be "primarily opinion based". For some reason SO thinks this is bad or different from other answers which in general are also opinion based given questions seldom have a single answer.

This is a reasonable question.

If we were to limit the scope of the question to simply DivisionByZeroError and Arithmetic error, then I think you should follow PHP's standardisation here, and leverage those errors. This moves you closer inline with the principle of least astonishment in that it makes your code in-step with expectations one would have with one's own code it one - for example - divides by zero. So this is a good thing (I think one can objectively say that).

However - now this is subjective - I would not be actively throwing those errors, I'd simply be letting my code error. IE: don't trap the situation and re-throw the same error, just let the code error. It simplifies your code (objective), and has the same end result (objective). So this ties into your instinct that one oughtn't throw these built-in errors. But only because it's not necessary: PHP will deal with that for you. I would not intrinsically say one should not actively throw these errors, but I s'pose the situation in which it's legitimate (or even necessary) would be an unorthodox one, so it might beg the question if it's the right Error to throw.

As for non-specifically-catered for situations like RoundingNecessaryException vs RoundingNecessaryError... I think it makes sense to upgrade them to errors. I cannot find the reference in the docs just now (someone else might be able to, and update this?), but they state that Errors are for programming errors which a dev will need to change code to fix; and exception is just for exceptional runtime behaviour. Or words to that effect. So if one wants to make your method that might throw a RoundingNecessaryError work, one needs to do the necessary rounding. This is a code-time consideration, so an Error makes sense. I think this is slightly subjective as there's no cut and dried single answer for this, but I think the rationale is a fairly objectively sound one.