Thanks for the feedback.
Our errorHandlers are pretty similar, except I’m using an invokable class.
I also want to specify which logger and level to use for each error/exception that gets thrown, so it was easier for me to create a bunch of ‘custom exceptions’ and throw them where I needed them to be (instead of letting slim take care of it), like these:
abstract class CUSTOM_EXCEPTIONS {
#[USER-FACING] status code level logger message
const deprecated = [410, 100, 'WARN', API_LOGGER, "API for current App version was either deprecated or not found"];
const invalidCreds = [401, 101, 'INFO', API_LOGGER, "Invalid e-mail/password"];
#[API]
const questionableHash = [400, 200, 'WARN', API_LOGGER, "Password does not seem to be a hash generated by the App"];
const questionableAuthToken = [400, 201, 'WARN', API_LOGGER, "Auth Token does not seem to be generated by the API"];
#[DB]
const dbConnectionFailed = [503, 301, 'ALERT', DB_LOGGER, "DB connection error"];
const dbQueryError = [500, 302, 'ERROR', DB_LOGGER, "DB query error"];
}
This way my CustomHandler check first against a list of pre-made custom exceptions; if it’s not a custom exception it gets passed to the default logger and return with $response->withStatus(500)->withHeader(...)->write(...)
.
For instance, I decided to implement my own custom exception if my database fails to connect (which is why I created this Discourse topic) so I can send a 503 back instead of the default 500. Also, if I didn’t check for my database connection to be not null, PHP will throw an error (instead of the db connection) on the first query saying ‘cannot execute method xxx on null’, which doesn’t really explain why it was null in the first place. So in this case letting the error ‘bubble’ wouldn’t help me figure out what’s wrong.
So my idea is to intercept any custom exception first, then let anything that’s not custom become the default 500 status code with default logging and response.
You don’t think this is ok?