cakephp: Implement a more specific exception structure

This is a (multiple allowed):

  • bug
  • enhancement
  • feature-discussion (RFC)
  • CakePHP Version: 3.x

Currently the core uses some very generic exceptions here and there, where the only difference will be the message text, which isn’t something one should have to rely on for identifying the problem in a programmatic way. A good example for this is the SMTP transport, in a single send() call, there are 9 possible exceptions which are all of the generic type SocketException.

Personally I’m a big fan of having distinct exceptions for every type of error, as this makes identifying and responding to problems more easy. Sticking to the SMTP transport example, I’d think of exceptions like:

  • ConnectionFailedException
  • TimeoutException
  • ResponseErrorException
  • AuthenticationFailedException
  • PasswordRefusedException
  • UsernameRefusedException
  • InvalidAuthenticationMethodException
  • UnrecognizedCommandException
  • etc…

Another prominent example would be every usage of \Cake\Error\Exception\Exception, while this may be the only exception being thrown in a specifc method, differentiating will become cumbersome again once that specific method is being invoked indirectly.

So long story short, what I’d like to suggest is to eliminate the usage of generic exceptions throughout the whole core by adding

  • separate exceptions for every type of error
  • per sub/package base exceptions

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 4
  • Comments: 15 (15 by maintainers)

Most upvoted comments

Correct, that’s kind of what I was suggesting with per sub/package exceptions @ionas. Given that PHP has no exception interfaces, not every exception thrown in a package can make use of a base exception though, unless one would throw away the usage of specific built-in PHP exceptions and use custom ones only, which I think pretty much no one here would be a friend of 😃

I’ll start with some basic stuff once I have some more free time, and then we’ll see what people think about it.

I can definitely get behind having specific exceptions as long as they come with a nice error page explaining what they mean and what can be done about them.

I had to give a 412 response code and there was no exception.

Can we have exceptions for all the HTTP status codes? This would just be for the convenience of people using Cake.

@thinkingmedia I like your idea. This came to my mind before, too. Those HTTP status code exceptions could be used in an app as server but also as client in userland code, e.g. in case of a HTTP API client.

@inoas Yes I think that is what is being proposed.

because there surely could be cases where an error page may not really be overly helpful, but the ability to catch/identify specific exceptions would be.

I think that’s good guideline to follow. If we can’t come up with a good reason to try and catch specific errors or make an error page for them using a more generic exception class would work for me. What I’m most concerned about is having 100+ exception classes and each one is only used under very specific conditions.

In general it can be done for 3.next as throwing a less generic exception is BC afaik.

Not really. But throwing more specific exceptions is backwards compatible as long as the new exception is a subclass of the old exception.