Passport: Error handling

[rudolfdobias]

Http controllers have their own exception handler. In a trait.
Why?

This thing triggers only report method on the main ExceptionHandler and returns a plaintext response to the client without any chance to override.
Why?

There is some communication standard on every API and this error handling breaks it. Besides that, even in case of hard 500 it writes the error message to the client in plain text REGARDLESS the environment and production settings. All the SQL errors containing sensitive informations et vice versa are exposed.
GOD, WHY?

Only chance to override this is to write all the controllers again in project namespace. If these "prefabricated" controllers are here for making developer's life easier, why to hard-wire such crucial logic into them? Why not use a contract for injecting exception handler? If not, why not call the render method of application exception handler? Or anything else?

Regards,
RD

[rudolfdobias]

Sorry for rudeness, guys, I was too pissed off by another things to think straight.

Anyway, what's your opinion to this error handling behavior in controllers? Or - in a better case - do you have any advice how to solve this? Maybe I overlooked something. All I'm trying to accomplish is get the error messages through application exception handler in formatted form (and filter-off sensitive data) without rewriting (or forking) it entirely.

Apologies and thank you in advance,
RD

[EdwardNelson]

I really don't like that all errors are caught in the HandlesOAuthErrors trait

[KieronWiltshire]

Why was this closed, the dude is right and nothing has appeared to have changed?