PHP - Errores de usuario: throw exception vs http_response_code(500)

Estimados,
Buenas tardes, como están?
La idea del post es que me ayuden a definir un proceso de devolución de errores y poder manejarlos de manera agradable del lado del cliente.
Actualmente estoy desarrollando una app en la que desacople el front del back: por un lado tengo los html (sin código php en su interior) y casi por regla, cada html tiene un controller javascript que este es el que hace, por medio de ajax, la llamada a un .php con los parámetros que se necesita para el proceso.
Una vez terminado el proceso en el back, devuelvo un json y este lo tomo en el javascript y hago lo que se necesite:
Ahora bien, hay veces que desde el back quiero forzar un error/advertencia, por ejemplo, en el login, que la contraseña es incorrecta, actualmente esa regla la devuelvo normalmente con un json y en el front ingresa por el código antes mencionado (obviamente en el json que envío desde el back genero un objeto con un estado en particular distinto a las peticiones OK y el mensaje que deseo mostrarle al cliente), pero entre en una disyuntiva de si conceptualmente lo que estoy haciendo esta bien encarado (de mas esta decir que el desarrollo funciona y hace lo esperado), que quiero decir con esto, mi duda es si desde el back tanto las reglas de negocio que no pasaron con éxito (password incorrecto, clave caducada, etc) como una excepción lanzada (throw new ...) deben volver al cliente como readyState == 4 y this.status == 200 o esta bien provocar en el back un http_response_code(500) y devolver el json y en el cliente capturarlo como:

Espero se entienda, la duda es mas que nada conceptual ya que la app funciona bien. en estos momentos le estoy dando mucha importancia a la arquitectura y a tener un desarrollo con una buena base.

Saludos.-

Hola Gabriel, en si creo que esta bien manejado, es uno de los proceso que suelo utilizar para manejar validaciones del lado del cliente. Realizas una petición ajax y luego recibe un estado de respuesta junto con un json, el cual contiene los mensajes correspondiente de las validaciones. Una cosa que cambiaria seria el código de estado http, en lugar de ser 500 el cual hace referencia a un error interno del server, por un estado 422 el cual indica que la solicitud está bien formada pero fue imposible seguirla debido a errores semánticos.

Te comparto un link de la Wikipedia que habla de las cabeceras HTTP
https://es.wikipedia.org/wiki/Anexo:C%C3%B3digos_de_estado_HTTP

abZeroX, muchas gracias por la respuesta, me da una vista de otro desarrollador.
Como comente, el código funciona OK y hace lo esperado, la idea es mas que nada conceptual y arquitectónico.
Como para pasar en limpio, mi consulta es si es valido utilizar los códigos de estado de HTTP desde el back para lanzar distintos errores (http_response_code(...)), por ejemplo, desde javascript hago una petición ajax a un php, el php hace las validaciones y devuelve un objeto serializado a json (el objeto tiene un mensaje, un objeto con datos y un código de estado [0-ok; 1-error; 2-warning]), pero el back siempre devuelve ok todas las peticiones y lo que hace el cliente es pivotear según lo que reciba como código de estado en el json.
Por ejemplo para jquery.ajax hay que definir unas funciones genéricas para sucess, error y complete, cual seria el caso en el que el back devuelva respuesta y el cliente salta por error?
Saludos!

Hola, adjunto un pequeño ejemplo que capaz se adapte mejor a lo que estas buscando implementar. Utiliza ajax por medio de jQuery como tu mencionas, en lugar de usar los métodos success, error, y complete usa .then() el cual aplica el patrón promise, recibe dos callbacks como parámetro, la primera cuando todo esta OK y la segunda cuando ocurre algun error, el parametro jqXHR tiene varias propiedades entre ellas y .

Espero sirva.
Saludos!

• Http-Code.rar(1,0 KB)

abZeroX, muchas gracias, voy a revisar el código que me pasas.
La ultima consulta, a tu parecer, que sentido tiene desde un back, devolver al cliente un código de error con http_response_code(...)? conviene desde el back devolver todas las peticiones OK con un cierto estado y validarlas desde el front.
Por ejemplo, en el ejemplo que mencionas, se definen 2 func como callback, en que caso saldría por la func de error?
Saludos!