RFC - making the Exception class abstract View as Markdown

Kevin,

Hello!

This is my first post to the internals list so please forgive me if I have
not followed the rules precisely!

I've had an idea to improve how developers use exceptions within PHP. I'd
like to add an RFC but as per the instructions on the site
https://wiki.php.net/rfc/howto, I am sending this email first gauge
reaction as an initial idea.

The idea is to change the base Exception
http://php.net/manual/en/class.exception.php class to be abstract. The
reason for this is to encourage developers to extend it to create meaning
exceptions or use the standard SPL exceptions. The documentation states
that it's the base class for all exceptions, which kind of encourages my
thought process.

Too many times have I seen developers throwing Exceptions when what they
really needed was something that gave it context like
InvalidArgumentException or RuntimeException. Yes, I agree this is
something to tackle at code review (and I do) but I feel PHP doesn't help
the situation by making it an instantiatable class. I struggle to think of
a valid reason where it makes sense to throw the root Exception class.
Catching the root Exception class is a different matter and there are
perfectly valid cases for doing it.

So, what does everyone think? Is it worth me pursing the RFC with full
details of the idea or am I on my own with this one?

Many thanks!
Kevin

Changing the existing Exception class to be abstract would break a
metric ton of code. Simply on that metric alone it would be a hard
sell. I think you'd need an exceptionally strong justification for it,
beyond "using typed exceptions is better".

Instead, I think we should solve the problem with education. Perhaps
the documentation can better detail out why devs shouldn't directly
throw exception but instead use typed exceptions...?

My $0.02 at least...

Anthony

Hi!

Too many times have I seen developers throwing Exceptions when what they
really needed was something that gave it context like
InvalidArgumentException or RuntimeException. Yes, I agree this is
something to tackle at code review (and I do) but I feel PHP doesn't help
the situation by making it an instantiatable class. I struggle to think of

Indeed, it doesn't - but PHP doesn't have to be helpful for 100% of
every use cases. It is plain impossible as some of them are in direct
contradiction. Example - one use case is yours, maintaining a code
standard in a project with strict guidelines. Another - making a
langugage that is easy to use to most unsophisticated user for quick
prototyping. Where concerns about strict exception hierarchy may be well
below concerns of developer convenience and productivity.
Thus, in one case you may not want to use Exception and in another
Exception may be all you need. The conflict can be resolved very easily

• leave Exception as is and introduce a policy using one of the
  multitude of great code style tools available for the complex project.
  IMO it's much better than creating a huge BC break that excludes one of
  the use cases.
  --
  Stas Malyshev
  smalyshev@gmail.com

Hi Kevin,

Kevin Bradwick wrote:

Too many times have I seen developers throwing Exceptions when what they
really needed was something that gave it context like
InvalidArgumentException or RuntimeException.

Yes, I agree this is something to tackle at code review (and I do) but
I feel PHP doesn't help the situation by making it an instantiatable class.

In general I don't believe making a language be harder to use is the
correct solution for programmers doing things you don't like.
Designing a language should be focussed on enabling people to write
good applications, rather than trying to force a baseline of adequacy.

In particular for this case:
* Bad programmers would just switch to using another 'default'
Exception such as ErrorExcepton.
* Good programmers who usually use a specfic exception, but in
some scenario want to use an \Exception sensible reasons would just be
inconvenienced.

So to me, it seems this would only have downsides with no real upside.

Is it worth me pursing the RFC with full
details of the idea or am I on my own with this one?

If you did want to proceed with it, I think you would need to address
how much BC break it would cause, and why it would be worth it.

cheers
Dan