[artesanos-de-software] Excepciones entre capas y la localización de sus mensajes

[Joaquín Engelmo Moriche]

Buenas a tod@s :)

Hablar de excepciones daría para muchos hilos por esto antes de nada voy a poner el objetivo de este, sin entrar en discusiones de "checked y unchecked" (eso sería otro tema), ¿cuál sería una buena forma de implementar la lógica de excepciones entre capas con vistas a localizar (i18n) sus mensajes?

Me voy a explicar:

- Tenemos un módulo que genera informes a partir de una estructura de datos. Esa estructura de datos se rellena en un formulario Web, al hacer submit se pasa a un controlador CRUD y esté lo envía a la implementación del servicio que genera informes. Varias capas intento representar.

- El módulo que genera informes arroja para comportamiento anómalos (ya sea por la funcionalidad que satisface o por errores de tipo conversiones o así) una excepción propia llamada ReportesException. De esta forma la capa controladora es consciente que necesita capturar está excepción en concreto para informar al usuario en Web de errores ante la generación de informes.

- Aproximaciones:

1) En el módulo que genera las excepciones, se "hardcodea" los mensajes al estilo:

"throw new ReportesException("la fecha de emisión debe ser posterior a la fecha actual")"

con lo cuál la capa controladora captura la excepción y muestra al usuario un "e.getMessage()". Vale, funciona, pero todos sabemos el gran inconveniente de esto a la hora de editar los mensajes, cambiarlos o decidir internacionalizar la aplicación.

2) Me creo un fichero de properties con los mensajes al estilo:

"fecha.incorrecta = la fecha de emisión debe ser posterior a la fecha actual"

Modifico la lógica de ReportesException para que sea:

"public class ReportesException extends Exception {

     private Properties messageFile = new Properties(getClass.getResourceAsStream("/exceptionMessages.properties"));

     

     public ReportesException(String errorMessageCode) {

          super(messageFile.getProperty(errorMessageCode));

     }

}"

Ahora cuando genere la excepción en vez de pasar el mensaje literal, paso el código que equivale al mensaje "throw new ReportesException("fecha.incorrecta")". He arreglado lo de los mensajes "hardcodeados" pero eso de leer el fichero de properties de forma estática en la declaración del atributo... no sé... funciona también claro.

3) ¿De quién es la responsabilidad de los mensajes? ¿Tiene que viajar la excepción con él o vale con el identificador? ¿No debería ser el controlador quién al final obtenga esa mensaje de un fichero global de i18n y lo mostrase?

Siguiendo esta aproximación, el controlador sería quién tendría un registro global de mensajes a localizar "messages_es.properties" al estilo el fichero del punto 2) y la excepción lo que transporta es el código del mensaje a mostrar de tal forma que la implementación cambia ligeramente a:

"public class ReportesException extends Exception {

     private String errorMessageCode;

     

     public ReportesException(String exceptionMessage, String errorMessageCode) {

          super(exceptionMessage);

          this.errorMessageCode = errorMessageCode;

     }

     public Strin getErrorMessageCode() {

           return errorMessageCode;

     }

}"

Así, no hay que realizar lectura ninguna de fichero de mensajes, lo cuál debería hacerse en la parte final de la aplicación que será, al final, quién deba mostrárselo al usuario. El controlador, al capturar la excepción tendría que obtener el código de error y ya hacer con él lo que corresponda para imprimir el mensaje. De todas formas, en el constructor de la excepción estaría bien poner un "exceptionMessage" por si viene de una IOException o algo así para el log del servidor o la consola de administración. Recordando cosas de libros siempre hay que mostrar una excepción acorde con el usuario y registrar algo más concreto y técnico para poder llevar a cabo el soporte por el equipo de desarrollo.

¿Cuál me parece, a mi, la mejor opción? La tercera. Pero espero que en este hilo salgan la 4), la 5), la 6), etc. Es una duda/pensada en alto que quería compartir con vosotros. El tema de las excepciones siempre me produce muchas dudas y debates a la hora de afrontarlas. Ya caerá otro hilo al respecto, ya :)

Aquí lo dejo para que os entretengáis :) Gracias de antemano! 

Un saludo

--
"Compartiendo el agilismo"

Agile Open Space 2010 - Barcelona 12 y 13 de noviembre

http://www.aos2010.agile-spain.com/

[José Manuel Beas]

En mi opinión, una excepción debe dar suficiente información como para que el objeto que la debe interpretar pueda componer un mensaje para un humano o dar información a un tercer componente que lo necesite. En tu caso, la excepción ReporteException es poco semántica. Quizás podrías ser un poco más explícito: ReportValidationException y como mensaje dar el nombre de la validación que se ha incumplido o algo así. De esta manera, el controlador (la Action, supongamos que es Struts) que llamó al modelo (supongamos que llama a un servicio de informes) podrá, por el contexto de la llamada y la excepción resultante, componer el mensaje localizado para que la vista (supongamos la JSP) lo presente al usuario de una manera amigable.

En una aplicación que hicimos hace tiempo planteé que todos los beans (Spring) de negocio (inconscientemente eran servicios) estarían "flanqueados" por un MethodInterceptor que nos aseguraba que cualquier Action que llamara a uno de estos componentes sólo podría recibir una BusinessException. (La hice checked y así obligaba a los programadores a tenerla en cuenta. Lástima que algunas veces hacían catch(BusinessException e) {}) :-( Pero bueno, por lo menos me evitaba muchos Error 500 en la aplicación. Sin embargo, con el tiempo me he dado cuenta de que eso es una medida paliativa en vez de una cura. Hay que ser mucho más consciente de las excepciones entre capas porque de lo contrario (con cosas como ese Interceptor) lo que hacemos es ocultar defectos que ocurren en las capas inferiores por nuestra propia ineptitud.

Un saludo,
Jose Manuel Beas

http://agilismo.es

http://jmbeas.iexpertos.com

http://twitter.com/jmbeas

[German DZ]

El problema que veo con este enfoque es que no tienes realmente varias capas o de tenerlas sus responsabilidades están "pobremente" definidas.

La excepción de la capa de servicios solo debería indicar que ocurrió en ese contexto, luego el controlador deberá poder interpretar eso y proveer toda la info para que la capa de presentación decida que hacer con eso.

En la capa de presentación, si es que ésta decide que la información se presenta al usuario final, será quien en el contexto de ese usuario deberá presentar un mensaje acorde que lo preparará en base a la información que el controlador le entregó. Por lo tanto recién la presentación se ocuparía de cosas de i18n.

Aclaro mi postura de rotundo rechazo a presentar información al usuario sobre lo que ocurrió... no es el destinatario de esa info y el pobrecito no tiene ni idea de que hacer con eso. La info detallada es para el administrador, y en todo caso al usuario en lugar de un "error 12304: DB not available" sería mejor un "problema con identificación #1234234" y los posibles pasos a seguir (si puede intentar otra vez, si debe esperar, si no debe preocuparse, etc) donde ese número es una referencia para que el administrador pueda ver en los logs cual fue el problema referido por el usuario.

GermanDZ

2010/11/7 Joaquín Engelmo Moriche <kiniso...@gmail.com>

[Joaquín Engelmo Moriche]

Totalmente de acuerdo con lo que se ha dicho hasta ahora de presentar información "técnica" al usuario, como dice German, que va a hacer el pobrecito con eso... Soy partidario de, si corresponde, mostrar una serie de pasos o posibles soluciones, etc... pero bueno, aparte de eso que me "desenfoco" del hilo, creo lo que comentas JMBeas es prácticamente lo que expongo en la aproximación 3) y, eso, unido a lo que dice German de que la capa presentación, en este caso es así, es la responsable de la i18n, sería quién tuviera esa responsabilidad de interpretar la excepción y componer el mensaje acorde. 

Por tanto, la idea es componer una excepción con los elementos necesarios para las capas superiores y, por supuesto, no ocultar nada con try...catch vacíos, sino lanar los mensajes detallados y técnicos a sistemas de log y consolas de administración, que para eso están, y luego simplemente darle al usuario algo de feedack que será más o menos completo dependiendo del caso. Con respecto al problema que planteaba, el cuál se va a plasmar en una aplicación real en producción, mis acciones van a ir en ese camino.

[Eduardo Ferrández]

Hola:

Creo que en general los literales deben resolverse en la capa más cercana al humano posible, aunque esto tampoco debe tomarse como un absoluto. Pongamos que tengo un servicio que intercambia json para ser consumido por cualquier tipo de cliente que tenga acceso a dicho servicio ¿debo enviar el código del mensaje o también su traducción? En principio podría ser suficiente con enviar el código del mensaje y que el cliente lo muestre al usuario como mejor le parezca. Pero también podría ser una ventaja enviar la traducción del mensaje (junto con el código) por dos motivos: tenemos un json más "human readable" y por otro lado, si el cliente no quiere complicarse implementando i18n, podría ser suficiente con mostrar la traducción que le proporciona el servidor.

Por otro lado, en cuanto a las excepciones, independientemente de ser checked o unchecked, podemos considerar que pueden ser recuperables o irrecuperables. Las recuperables son las que el sistema es capaz de tratar (por ejemplo, del estilo a InvalidDateException) y las irrecuperables aquellas que no sabríamos cómo tratar y cuyo único tratamiento posible es el clásico mensaje genérico de error "Ooops, el sistema está experimentado dificultades". En ambos casos la excepción debe propagarse entre capas para evitar pérdida de información. El motivo: en general en una aplicación de gestión cualquiera de las dos excepciones tiene como consecuencia mostrar un error al usuario, a diferencia de un sistema de tiempo real o empotrado, donde la recuperación puede, por ejemplo, consistir en reiniciar el reactor nuclear ;) sin que el usuario intervenga para nada.

Finalmente, estoy de acuerdo con José Manuel en cuanto a lo de que no es buena idea parametrizar las excepciones con códigos de error, si no que la propia excepción lleve el mensaje implícito (p.e. InvalidDateException) y no perder así semántica. El mensaje ya será resuelto cuando se recupere la excepción.

[German DZ]

Sí, por favor.. nada de códigos; la excepción debe ser suficiente, el código para dar algún matiz.

Respecto al JSON, si debe llevar algo de presentación no está mal que eso lo "enriquezca" la capa de presentación, así sea un servicio.. la info será la info (un array? una estructura de objetos?) pero el JSON es solo una forma de presentación de la info, otras alternativas son HTML, XML, txt, csv, etc. (ver por ejemplo HMVC http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/)

<mode="formula1" status="on"/>

2010/11/7 Eduardo Ferrández <eduardof...@gmail.com>

[Carlos Ble]

Hola!

No te hagas tu toda la fontaneria para la i18n Kini, usa algo que ya
este hecho.
En nuestra web, las excepciones tiene un mensaje tipo codigo (ej,
invalid-username) que cuando
llega a la capa de presentacion se le da al framework para que la
traduzca por
el idioma que el usuario tenga. Nosotros nos despreocupamos de
presentar la traduccion.

Saludos :-)

On 7 nov, 15:03, German DZ <g...@ndz.com.ar> wrote:
> Sí, por favor.. nada de códigos; la excepción debe ser suficiente, el código
> para dar algún matiz.
>
> Respecto al JSON, si debe llevar algo de presentación no está mal que eso lo
> "enriquezca" la capa de presentación, así sea un servicio.. la info será la
> info (un array? una estructura de objetos?) pero el JSON es solo una forma
> de presentación de la info, otras alternativas son HTML, XML, txt, csv, etc.

> (ver por ejemplo HMVChttp://techportal.ibuildings.com/2010/02/22/scaling-web-applications-...
> )

>
> <mode="formula1" status="on"/>
>

> 2010/11/7 Eduardo Ferrández <eduardoferrand...@gmail.com>

[gnz]

Yo tengo una pregunta... y antes de nada, perdón por irme por otro
camino, pero esas excepciones que lanzas, ¿por qué las lanzas? Quiero
decir, no sé si he llegado a entenderlo del todo bien.

Porque, por el ejemplo ("la fecha de emisión debe ser posterior a la
fecha actual", "fecha.incorrecta" o como prefieras), parece que se
trata de una validación. Es decir, si lo he entendido bien:
1. recibes determinados datos desde un formulario web
2. los metes en una estructura
3. se los pasas al al servicio que genera los informes
4. resulta que el servicio que genera los informes está recibiendo datos
que no son válidos y entonces lanza excepciones diciéndolo.

Pero digo yo, en mi abundante ignorancia e ingenuidad, ¿no sería más
lógico que esas validaciones ocurrieran antes de pedirle al servicio
que genere un informe? Seguramente digo alguna tontería pero ¿no sería
mejor validar los datos antes y que esa validación devolviera los
posibles errores (que entiendo que además pueden ser varios, no sólo
uno) de una forma más **normal** que con una excepción?

gnz/vnk

[Joaquín Engelmo Moriche]

Por supuesto "gnz" :) Es un ejemplo para fines didácticos, no más. Lo suyo sería poner algo que no se pudiera validar tan simple como eso de la fecha desde el mismo formulario o así pero no quería complicarme la vida buscando ejemplos ;)

Esta claro que dejar pasar toda esa información entre capas sin hacer nada por validarlas o lo que sea no sería lo más adecuado. Serían ganas de complicarse la vida! :D

[José Manuel Beas]

Cuidado con los ejemplos didácticos que terminan convirtiéndose en recetas por virtud del "aquí siempre se ha hecho así".

Estoy con Gonzalo, pero a medias. Es ideal hacer todas las validaciones antes. Pero en general no puedes garantizar que un servicio reciba los parámetros validados. Especialmente si lo llamas desde otra capa. Para mi, otra capa es como un producto independiente que debería estar, idealmente, en un proyecto diferente. Si lo tratas así es más fácil luego crear otros canales de acceso a la aplicación (a los servicios).

[jcesarperez]

Hola a todos.

Nosotros usamos la opción 3 pero con constructores diferentes. Un
constructor con un parametro String para el mensaje o el codigo i18n y
otro constructor con el parámetro anterior más un Throwable. Por lo
demás estoy de acuerdo con todo lo comentado.

Respecto al asunto de las validaciones que comenta Gonzalo, para mi es
correcto que se haga esa validación a nivel del servicio o lógica de
negocio. Lo cual no quita para que se detecte antes en cliente si es
factible.

Un saludo.
Julio.

[German DZ]

Yo asumo que era solo por poner un ejemplo. De todos modos una excepción del tipo ClienteNoAceptableException cuyo motivo sea: fechaAltaPosteriorPromocion es algo que solo sabrá el servicio de Facturacion cuando reciba laNotaDePedido y codigoPromocion. Distinto es que la capa que usa el servicio le pase como codigoPromocion algo que no sea válido, no tiene mucho sentido permitir eso si es que se pueda validar, sin embargo el servicio también debe asegurarse. La doble validación algunos la ven horrorosa, pero en realidad es obligada algunas veces y otra veces nos mejora mucho la performance y nos evita consumir recursos costosos (supongamos que el servicio debe hablar con un sistema remoto, para que perder tiempo y gasta ancho de banda para que me valida algo que yo ya puedo saber antes).

2010/11/7 Joaquín Engelmo Moriche <kiniso...@gmail.com>

Por supuesto "gnz" :) Es un ejemplo para fines didácticos, no más. Lo suyo sería poner algo que no se pudiera validar tan simple como eso de la fecha desde el mismo formulario o así pero no quería complicarme la vida buscando ejemplos ;)

[Eduardo Ferrández]

Qué tarde de domingo más productiva!

Varios comentarios que quiero hacer respecto a lo dicho:

Germán: cierto, he dicho json como podría haber dicho cualquier otro formato de representación de información más o menos estructurada. Lo que quería decir es que en ciertos casos podría ser interesante resolver los mensajes i18n previo presentación, como por ejemplo servicios que publicas en internet y donde tu objetivo es que sean accesibles al mayor número de aplicaciones posibles. Si alguien no quiere montarse su propia gestión i18n, ya se lo pasas tú traducido.

Gonzalo: El ejemplo era malo, pero hay validaciones que obligatoriamente deben realizarse dentro de una transacción, como por ejemplo, averiguar si hay stock suficiente en un almacén sobre el cual estás haciendo un pedido.

En cuanto al asunto de los ejemplos, yo espero que nada de lo que se dice aquí se tome como un absoluto, por dos motivos: en general nada es absoluto y por otro lado, establecer un contexto completo es muy difícil, por lo que comprender lo que dicen los demás requiere cierto grado de flexibilidad e incluso buena voluntad. Otra opción sería intercambiar preguntas y respuestas usando software funcionando, pero lo veo un poco complicado ;)

[gnz/vnk]

Aclaro una cosa.

Mi pegs no era tanto con el tema de dónde se hagan las validaciones (entiendo que sólo era un ejemplo) cuanto con el motivo de lanzar una excepción.

Es decir, para mi, un proceso en el que el input debe ser validado, debería poder devolver errores como algo más natural, no como excepciones. Entiendo que son esos los mensajes susceptibles de mostrarse al usuario (i.e. no son nullpointer, io, etc, sino "falta este dato" o "este dato no vale").

En esos casos, que entiendo que son susceptibles de i18n y que serán mostrados al usuario, y en un proceso que en un momento (el que prefiráis) realiza esa validación, devolver sos errores debería ser más **normal** que **excepcional**.

Gonzalo

gnz/vnk

[Eduardo Ferrández]

¿Qué tienen de antinatural las excepciones a la hora de devolver errores?

¿qué código es más legible?

Este:

error = compruebaExisteStockEnAlmacen();

if (error != null) {

    trataError(error);

} else {

    error = compruebaClienteTieneSaldo();

    if (error != null) {

        trataError(error);

    } else {

        error = realizaPedido();

    }

}

¿O este?

try {

    compruebaExisteStockEnAlmacen();

    compruebaClienteTieneSaldo();

    realizaPedido();

} catch (Exception e) {

    trataError(e);

[José Manuel Beas]

Mejor incluso:

 

try {

    compruebaExisteStockEnAlmacen();

    compruebaClienteTieneSaldo();

    realizaPedido();

} catch (NoExisteStockEnAlmacenException e) {

    trataError(e);

} catch (ClienteNoTieneSaldoException e2) {

    trataError(e);

}

 

;-)

Un saludo,
Jose Manuel Beas

[gnz]

Hombre, tampoco creo haber sido tan vehemente, no? Una cosa es que me parezca más natural A y otra que B me parezca antinatural. Simplemente me parece "menos natural" :)

Lo que ocurre es que entiendo que es una validación de un formulario de datos de usuario. Puede, y en mi experiencia es relativamente común/frecuente/habitual/natural, que el usuario cometa errores al rellenar los datos.

El sábado fui a correos a enviar un paquete. Al llegar allí, seleccioné del menú de acciones (le dije a la simpática señorita) que quería enviar un paquete certificado. Me presentó un formulario que rellené como mejor supe con los datos que tenía. Hay veces que tengo alucinaciones muy vívidas y tras darle el formulario y que intentara meterlo en la máquina, vi cómo ella recibía una descarga eléctrica que recorría su cuerpo interrumpiendo completamente su proceso. Inmediatamente pulsó una alarma y el cartel de DEFCON 3 se encendió con una sirena ensordecedora. Me devolvió el formulario diciendo "El campo NIF es obligatorio".

Afortunadamente, era sólo una visión. La mujer cogió el formulario con tranquilidad, y antes de nada, lo repasó y me dijo simplemente "Tienes que poner aquí el NIF y te falta también el código postal de orígen".

La diferencia, más allá del espectáculo de luces y sonido, es importante. En el primer caso, un error de datos de usuario es una circunstancia excepcional, que rompe el flujo normal de la aplicación. En el segundo, la validación de datos supone una parte normal del proceso y un error no *interrumpe* el proceso sino que lo *desvía*.

De hecho, tras enviar el paquete sí que ocurrió algo excepcional. La cinta de recibos de la máquina se atascó. Entonces sí, ella interrumpió su proceso habitual para levantarse y tratar de sacar el recibo sin dañar o en caso de que se rompiera, imprimir otro.


En cuanto al código que pones... entiendo que no representa lo que intento decir. La idea es transformar esto:

try {
    makeReport(data);
} onHellBreakingLoose(hell) {
    is(hell).because(data -> notValid)? showErrors();
    is(hell).because(machine -> broke) apologize();
}

en algo más parecido a lo siguiente, donde la validación de datos ocurre de manera más consciente:

userErrors = validate(data);
if (userErrors.size > 0) tell(user).toFix(userErrors);
else try {
    makeReport(data);
} onHellBreakingLoose(hell) {
    is(hell).because(machine -> broke) apologize();
}

Y ojo, que las excepciones siguen representando "errores". Lo que ocurre es que no todos los errores son iguales. No todos los errores son excepcionales.


(Todo esto, evidentemente, no es más que mi modesta opinión. Y no pretendo ni convencer a nadie ni tener razón, ok? De hecho, yo apenas soy un novato en esto. simplemente comento mi opinión y si me equivoco pues me lo decís. Pero vamos, que no he dicho que las excepciones sean antinaturales.)

Gonzalo

gnz/vnk

2010/11/8 Eduardo Ferrández <eduardof...@gmail.com>

[German DZ]

Muy bien explicado, a mi también me gustan los cuentos e historias para explicar (aunque muchos dicen que no son muy académicos!).

Algunas cosas:

La validación de NIF obligatorio, claramente la hizo "la interfaz" y no el proceso. Y así debe ser.

Las excepciones no son errores, son "excepciones" por suerte han elegido buenas palabras para que la semántica de nuestro código se mantenga. Cuando en un catch atrapamos una excepción, ahí es donde o bien la transformamos en error irrecuperable o bien hacemos algo alternativo.

Recordar que las excepciones debemos lanzarlas por egoísmo, es decir que cuando en el contexto de responsabilidad no podemos tomar ninguna otra decisión. Entonces somos egoístas y nos mantenemos en nuestra misión sin involucrarnos en lo que nuestro trabajo impacta en los demás. [Nosotros y yo somos una clase en este caso!]

2010/11/8 gnz <gnz.g...@gmail.com>

[Eduardo Ferrández]

(Todo esto, evidentemente, no es más que mi modesta opinión. Y no pretendo ni convencer a nadie ni tener razón, ok? De hecho, yo apenas soy un novato en esto. simplemente comento mi opinión y si me equivoco pues me lo decís. Pero vamos, que no he dicho que las excepciones sean antinaturales.)

Gonzalo, he usado un término absoluto como "antinatural", pero como ya dije previamente, en este tipo de debates todo debe ser relativizado. Disculpa si te ha molestado.

Por otro lado, cuando doy mi opinión yo tampoco busco convencer a nadie ni tener razón. Entiendo los debates como pura dialéctica hegeliana, donde uno afirma algo, otro contrapone y de ahí puede surgir un nuevo concepto que acerca posiciones y nos ayuda a mejorar y reflexionar. Sólo eso. No busco tener +1s ni aplausos. Si a veces parezco agresivo o competitivo, lo lamento, nada más lejos de mi intención.

[gnz]

2010/11/8 Eduardo Ferrández <eduardof...@gmail.com>

Gonzalo, he usado un término absoluto como "antinatural", pero como ya dije previamente, en este tipo de debates todo debe ser relativizado. Disculpa si te ha molestado.

No me ha molestado, Eduardo, tranquilo. Simplemente he pensado que quizá no se me había entendido bien. Y es sólo eso, que si alguien dice que A le parece /mejor/, no está diciendo que B le parezca /mal/. (Al menos en mi caso :) ) Y, vaya, antinatural suena muy fuerte xD

gnz/vnk

[German DZ]

Está bueno que cada uno a veces explique lo que entiende por ciertas palabras. Particularmente suelo ser muy afirmativo en lo que digo, por el simple hecho que no digo cosas que no crea que son así. Pero está muy bien que así sea "hay que mojarse"; el simple hecho de contraponerse a otras posturas hace que surjan otras ideas al poner a pruebas las nuestras.

En fin, ni somo griegos ni filósofos (bueno, algunos si), pero el ejercicio es bueno. Aprender a decir no y a escuchar a ideas disonantes para nutrirse de ellas hace bien.

Antinatural no me suena fuerte... si me dicen antinatural significa que para otros ese punto de vista no está en la lista de los posibles imaginables en primera instancia; es para pensarlo... una cuestión importante es lograr que podamos comunicarnos, mediante el código cuando somos los artesanos del mismo y por eso si otros no son capaces de captar la esencia algo ocurre. También hay que pensar que si yo veo algo que no lo siento natural, la pregunta debe ser ¿son ellos o soy yo? Para mi el código funcional no es el más natural, pero eso es porque hace como 20 años que no veo ese tipo de código.

2010/11/8 gnz <gnz.g...@gmail.com>

[jcesarperez]

¿Cuándo es un error de usuario y cuándo una excepción?

Para mi, si el usuario no rellena el nif, es un error del usuario. Un
error que detectaré y trataré en mi código de la parte cliente y, por
si acaso, en el controlador de la parte servidor correspondiente.
Ahora bien, si el nif no le llega al método de servicio o dao de turno
y es un campo obligatorio, entonces es una excepción. Las manejo con
el típico Assert.notEmpty(nif) que me permite ver el contrato de ese
método en las primeras líneas de forma muy efectiva. Otra opción sería
usar anotaciones...

On 8 nov, 10:08, German DZ <g...@ndz.com.ar> wrote:
> Está bueno que cada uno a veces explique lo que entiende por ciertas
> palabras. Particularmente suelo ser muy afirmativo en lo que digo, por el
> simple hecho que no digo cosas que no crea que son así. Pero está muy bien
> que así sea "hay que mojarse"; el simple hecho de contraponerse a otras
> posturas hace que surjan otras ideas al poner a pruebas las nuestras.
>
> En fin, ni somo griegos ni filósofos (bueno, algunos si), pero el ejercicio
> es bueno. Aprender a decir no y a escuchar a ideas disonantes para nutrirse
> de ellas hace bien.
>
> Antinatural no me suena fuerte... si me dicen antinatural significa que para
> otros ese punto de vista no está en la lista de los posibles imaginables en
> primera instancia; es para pensarlo... una cuestión importante es lograr que
> podamos comunicarnos, mediante el código cuando somos los artesanos del
> mismo y por eso si otros no son capaces de captar la esencia algo ocurre.
> También hay que pensar que si yo veo algo que no lo siento natural, la
> pregunta debe ser ¿son ellos o soy yo? Para mi el código funcional no es el
> más natural, pero eso es porque hace como 20 años que no veo ese tipo de
> código.
>

> 2010/11/8 gnz <gnz.gar...@gmail.com>
>
> > 2010/11/8 Eduardo Ferrández <eduardoferrand...@gmail.com>