It's been the same query that's been failing for me, alternating between error 127 and error 28. Been seeing more of the 28 the last couple of days, before that it was 127 which was a bit more ambiguous.

What I've done with my own systems is restricting the error dumps on a member level basis, and ensured that fatal error level crashes with debug dump don't happen to begin with. Been working well enough so far. Admin gets the full debug dump with queries and PHP errors, Members get a message see more telling them there's been an error and the Admin has been notified, and the full error dump is logged to database on the background in all cases.

Instead of implementing a full error handler, I've simply switched on output buffering as a capture device, the contents of which I analyze against keywords (as either PHP/MySQL/random output) and categorize, and clear the buffer after it goes through the error handler. (MySQL errors have a separate handler that logs a bit more detail.) Since PHP doesn't allow fatal level error interception in either case, all you can really do in that department is to try to ensure that areas of code with potential for fatal error are immune to missing input from the get-go.