I have an app in which we have a custom database abstraction class. It's all nicely tuned and works pretty well.
We have recently added better error logging to file and database for query and connection errors.
One thing we've found ourselves wanting is the ability to run a trace on the files involved in the call. I.E to remove an old bit of code etc.
We have used some output buffering, with debug_print_backtrace() but am not satisfied with the disorganised output this puts to log.
Any one come across a nice handler for this which makes terminal log reading beautiful?
Also the app is fairly legacy code and queries are very much mixed into views and output. Is there any safe way that we could force a redirect to an /error.php page if a query fails without re-writing the app?
You asked a couple different questions.
First, have you looked at debug_backtrace()? It provides a lot of information and will give you the ability to control the look and amount of information within your logs. Granted, you'll have to do some work to get the info into the logs, but it should do the job nicely.
Regarding the redirect to an error.php page without re-writing the app, you'll have to rewrite something. In theory, you could modify your abstraction class to redirect a user upon failure. Having said that, I would argue that's not the best place for such an operation. If it were me, I would rather the abstraction class return an exception and have the app contain all the user-facing logic to handle it. Otherwise you end up creating a leaky abstraction that could end up being more technical debt to address in the future.