Claro, y el cliente de ese método ataja una exception y suponete que la
logea con su backtrace. Cuando mires ese log, sabés que hay un StandardError
que surgió en tu método, línea 5, pero no te dice nada de toda la
información que tenía e (su clase, su mensaje y su backtrace).
En este ejemplo, vos te tomaste el trabajo de traducir toda la información
de e en el mensaje de la que estás lanzando. Eso se puede hacer sólo en los
casos más triviales (en este caso, por ejemplo, el backtrace de e no te
interesa, pero imaginate si en lugar de "0/0" se invoca a una API que no es
tuya y resulta en un backtrace profundo)...
La solución particular (encadenar excepciones, o Composite Exceptions como
alguien les dice en el Wiki C2) puede no parecer la más elegante (es quizá
compleja), y ciertamente tiene cierto olor cuando la evalúo desde Ruby.
Esperaba encontrar algún idiom en Ruby que lo reemplace y me sorprenda. Se
puede por supuesto monkey-patchear* StandardError (estamos en Ruby a fin de
cuentas), pero es importante que sea algo consensuado (no quiero hacer
analogías, pero es similar a la situación en Java pre-1.4, donde cada uno
usaba una API ligeramente distinta para encadenar excepciones).
* "Monkey-Patch" se refiere a cuando abrimos una clase/módulo ya definida/o
para redefinirle métodos y esas cosas. Preferí no traducirlo, pero no quiero
empezar un flame-war (¿¿guerra de llamas??) al respecto (ya una vez hubo
algo, si mal no recuerdo).
¿¿¿Oscurecí???
nachokb
On 9/5/07, Emilio Tagua <[EMAIL PROTECTED]> wrote:
>
> On 9/5/07, NachoKB <[EMAIL PROTECTED]> wrote:
> > Hola gente del grupo,
> > viniendo del mundo de Java, en su momento aprendí a tomarle el
> > gustito al tema de las Chained Exceptions, un mecanismo que provee la
> > Exception base de Java (en realidad <<i>> Throwable) desde la versión
> > 1.4 (anteriormente había n versiones duplicadas, siendo n la cantidad
> > de programadores Java en el mundo).
> > Este mecanismo permite wrapear excepciones de un nivel inferior al
> > que estamos trabajando para transformarla de manera que el cliente no
> > deba lidiar con exceptions que sean crípticas y específicas de una
> > implementación, sino sólo con otras que formen parte de la API del
> > servicio que se está proveyendo (imaginen si un_model.save! lanzara un
> > "NameError").
> > Normalmente se rescata una exception y se lanza otra, pero el
> > problema es que en ese momento se pierde toda la información (clase,
> > message y backtrace) de la originaria, que resulta útil para debug.
> >
> > Obviamente, esto salta cuando se intenta crear alguna abstracción (no
> > cuando nosotros somos los clientes).
> >
> > El tema es que en Ruby no encuentro algún mecanismo similar, y
> > mirando los fuente de ActiveRecord me encuentro que no se usa (de
> > hecho, se ataja una y se lanza otra sin más).
> >
> > ¿Alguien alguna vez tuvo alguna experiencia al respecto? ¿Algún alma
> > ex-Java convertida?
> >
>
> Algo asi???:
>
> begin
> 0/0
> rescue Exception => e
> p "Tu exception era: #{e}"
> raise 'Pero mejor aprende a dividir'
> end
>
> rescue y raise (para tirar otra) serian la solucion.
>
> Tiras una que vos creas u otra de las Built-in Exceptions.... No se si
> te entendi bien o era lo que buscabas, de cualquier manera suerte con
> eso!
> _______________________________________________
> Ruby mailing list
> [email protected]
> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
>
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
