Proper structuring of a Laravel application and where responses should be handled?

So at the moment my application is structured such that Controllers will access a "Processor" class for certain objects (Business logic). This processor object then accesses all the relevant repositories necessary to perform the action (Data access logic).

For instance, let's pretend there is a UserProcessor class which we are using to attempt updating the user's email via some function: updateEmail($user_id, $new_email). The validation is then handled on the email, but lets say this validation fails. Obviously there are multiple vectors by which the updateEmail function can fail. Many of these will throw exceptions, but in the case of the validation and a few others, they will not (they aren't totally unexpected errors thus an exception is not proper?).

My problem occurs because of the potential for multiple failures. I'm unsure how to handle updateEmail's non-exception type failures. I could just have updateEmail return a response object as necessary which solves everything. But something about this doesn't feel right, isn't the generation of a response object supposed to be handled in the Controller?

I could also create an errors variable, which the controller accesses on receiving False from updateEmail. But this ends up being very generic in-terms of my api, which returns "status", "message", and "payload". In my current form I have a generic message for errors like: "validation error(s) have occurred." and then in the payload specific errors are listed. I could create a errorMessage variable in my UserProcessor, but at this point I might as well return a response object as I need to also store the HTTP error code?

Am I overthinking this? Should the processor just handle responses?

via Chebli Mohamed