Propagación de errores en MVC

[SetheR]

Hola muy buenas noches a todos.
Estaba metido aquí en un pequeño proyecto y me he dado cuenta de aún no tengo una manera clara de propagar los mensajes de error de aplicación entre el modelo y el controlador. Me explico:

Imaginaros un método que pide un objeto de una base de datos.
Yo saco los datos y genero el objeto, pero a veces se pueden dar ciertos errores, como que no exista el ID pedido o que la conexión a la base de datos falle.

Cuando el método sólo tiene que manejar un error, pero tiene también que devolver un objeto (una noticia por ejemplo), devulevo NULL y explico el error en el controlador; pero cuando se trata de más errores la cosa se complica.

Actualmente, mi solución consiste en crear en objeto Resultado que contiene un booleano que dice si el resultado es el esperado o no; un campo con la lista de errores generados y otro que es el resultado en sí (el objeto pedido).

El caso, es que mi solución me parece poco elegante. He buscado por ahí aplicaciones "grandes" para ver como abordan éste problema, pero no he llegado a ninguna conclusión interesante.

¿Cuál es la manera en la que informáis al controlador de que ha habido un error vosotros?
Quizá le esté dando demasiadas vueltas y teniendo poco confianza en mis soluciones, lo sé, pero me interesa vuestra opinión.

EDIT: Extendiendo un poco lo anterior, he visto que en muchos proyectos utilizan las excepciones para manejar estos errores. Lo veo factible para algunos errores (por ejemplo una caída del db server), pero para otros, como contraseña incorrecta, me parecen desacertados, pues no se corresponden con un error de funcionamiento del programa..

Muchas gracias por leerme.

Un saludo.

[maycolalvarez]

Eso no tiene nada que ver, sí encapsulas un sistema de RBAC propio, puedes utilizar o definir Excepciones propias las cuales puedes capturar desde tus controladores con bloques Try, la POO no sólo se limita al desarrollo del framework, también puedes extender las funcionalidades relacionadas con tú lógica de negocios con ella.

[Smolky]

Hola. Como tú dices hay cosas que son excepciones y otras cosas que no.

No es lo mismo que un Item no exista en base de datos que un error de conexión.

Ahora, también hay que pensar lo siguiente:
Imagina que tienes un método que determina si existe un determinado Item en base de datos, un método llamado hasItem (Item item) y otro método que se llama getItem (item).

Podrías emplear el primero para asegurarte de que existe el item y luego el otro método para sacarlo, pero ya estarías haciendo dos comprobaciones en base de datos por lo que quizás sea más conveniente ser pragmático y definir eso como excepciones.

[SetheR]

Muchas gracias por la respuesta, las excepciones las tengo bastante claras, aunque creo que no todas las excepciones han de ser mostradas como errores al usuario (no le interesa cómo y dónde falla la aplicación). En los casos excepcionales, guaro los mensajes en un log.

Y es a éstos a los que me refiero, errores y no excepciones.
He visto que hay gente que utiliza códigos de error haciendo uso del tipado débil de PHP (unas veces devuelve el objeto y si hay error devuelve un int con el código), cosa que a mi no me gusta por el tema de portabilidad.

Mi problema concreto consiste en que en un request, hago una llamada "masiva" a varios modelos, y me gustaría tener controlados e informar al usuario en todo momento de todos los errores que vayan surgiendo, como errores de validación u otro tipo de errores, así como de mensajes que lancen las excepciones que considere oportunas.

Si aún creéis que las excepciones son la mejor forma de manejar éstos casos, ¿por qué?.

Simplemente me gustaría saber cómo abordáis vosotros éste problema y porque.

Saludos

[GatorV]

Las excepciones como tal son para eso, para casos excepcionales, no debes de manejar el flujo de tu aplicación usando excepciones, y como dices tú, al usuario solamente le debes de mostrar run mensaje de error y no una excepción.

Dentro de tu flujo de tu frontController debes de manejar un bloque try/catch para las excepciones y guardarlas en un log para su posterior análisis, pero como dice Smolky, para casos que debas de controlar debes de forzosamente regresar alguna información.

Por ejemplo el componente Zend_Auth de Zend, este tiene un método authenticate que puede ser correcto o no dependiendo de la información del usuario, por ejemplo:

Código PHP:

$result = $auth->authenticate($adapter);
 
if (!$result->isValid()) {
        switch ($result->getCode()) {
              case Zend_Auth_Result::FAILURE_IDENTITY_NOT_FOUND:
                    // mostrar error
        }
}
 

No devuelves como tal un error si no un objeto result, que puede ser o no válido, para casos como que no tengas un item en la base de datos puedes usar null para verificar, por ejemplo:

Código PHP:

$item = $model->getItem($id);
if ($item === null) {
        // show error message
}
 

O usar un esquema como el anterior, de devolver un objeto sin datos con un código de error:

Código PHP:

$item = $model->getItem($id);
if (!$item->isValid()) {
        // muestras error
}
 

Como tal formas de hacerlo hay muchas, todo depende del diseño de tu aplicación y que uses las excepciones para casos excepcionales (por ejemplo que no exista la conexión a la BDD, etc), ese tipo de acciones sí deben de lanzar excepciones que debes de cachar en tu frontController y ya de ahí solo mostrar un error genérico al usuario y enviar una alerta.

Saludos.

[HiToGoRoShi]

Crea un objeto generico para todo tus modelos, por ejemplo si quieres traer un lista de una tabla X hagamos algo asi

Código PHP:

class ResponseObject{
  private $_result;
  private $_error = false;
  private $_messageError;
 
  public setResult($r){ $this->_result = $r; }
  public setError($e) { $this->_error = $e; }
  public setMessageError($me) { $this->_messageError = $me; }
 
  public getResult(){ return $this->_result; }
  public hasError() { return $this->_error; }
  public messageError() { return $this->_messageError; }
}
 

y puedes hacer esto ...

Código PHP:

if($obj->hasError()){
 echo $obj->messageError();
}
 

Y ahi ya tu controlas todo, especificas el tipo de error, un mensaje por lo tanto nuestro getResult retornaria null, si algo salio mal, no existe el usuario especificado ?

Código PHP:

if($obj->hasError()){
 echo $obj->messageError();
/*Respuesta: el usuairo que intenta buscar no existe en nuestra base de datos */
}
 

Opcion B, pero creo que no te gusta yo la uso por un tema de tiempo ... trabajar con numeritos xD

[SetheR]

Muchas gracias a ambos. La solución que proponéis de un objeto "Result" que a parte del resultado contenga información sobre el mismo es la que estoy utilizando ahora mismo (y que mencioné en el primer post).

Entonces mi solución sí que era buena.
Y justo fue con Zend_Auth que me surgió la idea.

Muchas gracias a todos los que habéis respondido.