El 4 de agosto de 2010 16:28, Jose Gregoris <[email protected]>escribió:
> Hola Gallego > > GRacias , esta muy bueno el artículo . > Vos en que casos usas #error: ? > > No recuerdo haber usado mucho #error: Por lo general, en el nivel que trabajamos diariamente, creamos nuestros propios tipos de Exception (subclase de X). El articulo que te pasé debería ayudarte a entender cómo te conviene modelar tus tipos de Exception. Saludos GallegO > saludos > > --- El *mar 3-ago-10, GallegO <[email protected]>* escribió: > > > De: GallegO <[email protected]> > > Asunto: Re: [clubSmalltalk] StdioFileStream dolphin > Para: [email protected] > Fecha: martes, 3 de agosto de 2010, 20:02 > > > KiKoTe: (fijate que ya te invente un nick camel case): > > Tenés que leer este articulo: > * > * > *Exceptions by Design: ANSI Standard Exception Handling* > > http://www.cincomsmalltalk.com/userblogs/cincom/digest?content=2001-files-exceptions > > No se si ya no te lo pase alguna vez. Bueno, a mí me gusta mucho y lo > recomiendo a todo el mundo ja, espero no causar tanto daño. > > > Saludos > GallegO > > > > El 3 de agosto de 2010 15:08, Jose Gregoris > <[email protected]<http://mc/[email protected]> > > escribió: > > Hola Carlos , lista > > Contesto algunas cosas y otras las dejo para espues de masticar un poco. Me > voy a quedar sin dientes ajajajja > > . > > > En líneas generales estoy de acuerdo. Y no soy muy partidario de las > excepciones dentro del código de la aplicación. > Para una posición más extrema (y bien fundamentada) sobre el uso de > excepciones dentro del dominio de aplicación, podés preguntarle a Hernán > Wilkinson (que sí está en esta lista). > > > La discución esta habierta, me encantaría conocer mas opiniones y claro la > de Hernan tambien. Si tiene algun material de lectura y lo puede pasar, > sería genial. > Yo pregunto, la mayoria de las veces pocos contestan :( y casi siempre > son los mismos y se los agradezco > Entiendo que todos tiene trabajo, ocupaciones y muy poco tiempo o capas > nada para decir jajaja. > Como en el caso de la pregunta sobre: "Como usan ST" > > > > Hay otros temas, como, por ejemplo: > x.- el mecanismo de excepciones se complica cuando se disparan procesos > paralelos y debe heredarse manejadores de excepciones, etc. > Seguro, sería una complicación adicional. pero más para la VM y el > administrador de procesos que para el programador. > > Acá no entendí. > > > > > x.- el manejo de errores, a veces, quedan en lugares insólitos y no pueden > ser rehusados fácilmente (sino que debe ser planificado). > Totalmente en desacuerdo. El manejo de errores tiene que quedar donde hay > información para hacerlo, donde se conoce cuál era la intención de la > operación y hay una lógica posible para la recuperación. > Y si está en el lugar correcto, es parte del comportamiento del objeto y > puede ser reusado (rehusar es negarse) tan fácilmente como el resto. > > > A que te referís con (rehusar es negarse) ? > > > > > No lo sé. A mí me molesta un poco, pero me molestaría más discutirlo en la > lista de Smalltalking. > > Saludos > > Entiendo que hay diferencias entre Ale y personas que participan de la > lista y es una pena (tan pocos y tanto quilombo :( ). No me hago el dolobu > por eso aclaré antes. > La verdad es que no me interesa saber los porque, es algo que no puedo > manejar ni resolver > > > saludos y gracias de nuevo > --- El *mar 3-ago-10, Carlos E. Ferro > <[email protected]<http://mc/[email protected]> > >* escribió: > > > De: Carlos E. Ferro > <[email protected]<http://mc/[email protected]> > > > Asunto: Re: [clubSmalltalk] StdioFileStream dolphin > Para: > [email protected]<http://mc/[email protected]> > Fecha: martes, 3 de agosto de 2010, 13:55 > > > On 02/08/2010 11:50, Jose Gregoris wrote: > > Hola Carlos > > Perdón por la demora, pero estaba tratando de masticar un poco tu respuesta > y mi concepto anterior. > > No hay problema, los emails permiten recuperar los contextos :-) > > No me gusta citar a alguien que no participa de la lista ya que no > puede aclarar sus comentarios,pero en este caso deberé hacerlo para tratar > de aclarar mis dudas. > Esto es lo que encontré en los históricos de smalltalking. > Esto decía Ale reimondo en un mail , y hay otro comentario despues: > > Si, me refería a usar excepciones o usar #error: (o alguna > alternativa similar). > Cual es la diferencia? > En el caso de > self error: 'Ouch! que me paso?' > o algo similar (el mensaje puede no ser #error: sino > alguno más específico, lo cual permite SUBCLASIFICACION) > quien tiene la responsabilidad de resolver el error > es el objeto receptor en el contexto donde este ocurre > y con el grado de abstracción donde se gesta el error. > > En cambio en el mecanismo de excepciones, quien > maneja la excepcion NO es necesariamente el objeto > responsable del error. Incluso esta excepcion se > debe tratar de resolveren un contexto que (es muy > provable) no tiene información específica ni el mismo > grado de abstracción que el contexto donde el > error/excepcion se genero. > > En líneas generales estoy de acuerdo. Y no soy muy partidario de las > excepciones dentro del código de la aplicación. > Para una posición más extrema (y bien fundamentada) sobre el uso de > excepciones dentro del dominio de aplicación, podés preguntarle a Hernán > Wilkinson (que sí está en esta lista). > > Pero en este caso, estamos hablando de artefactos que de por sí ya son de > bajo nivel: un stdioFileStream y la librería de base que se conecta al SO. > ¿Qué chances tienen esos artefactos de resolver la excepción, aunque se > genera en su contexto? NINGUNA. No hay nada interesante que puedan hacer, > aunque sí muchas cosas molestas y peligrosas. > Si implementara #error: o inclusive fileNotFoundError: en StdioFileStream, > lo único que podría hacer es... generar una excepción. > > Esto es algo que pasa muchas veces: uno puede pensar que el mejor contexto > para resolver el problema, es el más cercano. Porque ahí todavía estamos > cerca, sabemos exactamente qué pasó y estaríamos en mejores condiciones para > resolver las cosas. Todavía no le respondimos nada feo o equivocado a nadie. > Pero en realidad, la semántica de la operación suele estar indicada mucho > más arriba. En estos casos, claramente es mejor que la excepción la maneje > el que pidió las cosas, no el que las está haciendo (que es un "tonto" de > bajo nivel). > Otro ejemplo clásico del manejo de excepciones: un Float recibe / con cero > como argumento. ¿Cómo va a manejar eso? No hay chance. > > > El manejo de errores por el mecanismo de excepciones > me parece adecuado cuando uno trabaja con lenguajes > de programación, donde el objeto no puede hacer mucho > ni el sistema puede cambiar demasiado (como para > generar errores inesperados). > > Entiendo que tratar de "adivinar" a partir de una excepción, en otro > contexto, cuál fue el problema y cómo solucionarlo es arriesgado. > Por eso también enfatizaba que hay que proveer excepciones claras y > específicas. Si "desde arriba" se ve un error genérico, los intentos de > solución son aventurados o necios, como esos carteles de Windows donde te > dice: "Su operación falló; tal vez usted hizo esto o tiene aquello o debería > revisar lo de más acá". Ahí se ve que tienen un error genérico, y conocen > tres posibles fuentes de ese error... > > En el caso de un sistema de objetos donde (debido > a delegación) el envío de un mensaje puede desencadenar > una anidación de contextos diferente en distintos > momentos del sistema (la delegación en objetos nuevos > activa otros métodos), el no atender un error (u otra > impureza del sistema) en el contexto donde se > genera/instancia te produce el riezgo de que el > error/impureza se propague a otras áreas o que no > pueda ser tratada adecuadamente (por llegar a un grado > de abstraccion muy alto, por ejm.). > > En resumen, es importante saber utilizar ambos > mecanismos y reconocer que no son equivalentes > sino complementarios. > > > Seguro... pero eso no dice nada nuevo. > > > > > ------------------------------------------------------------------------------------- > > > En Smalltalk hay dos formas de manejar errores (hay un mail sobre el tema > en > la lista): > 1.- atención por parte de otro objeto (excepciones). > 2.- atención por parte del objeto responsable (receptor). > > El mecanismo (1) posee dos características que hacen que no sea completa: > a) a menudo el manejador de la excepción no posee conocimiento sobre que es > lo que ha ocurrido realmente o en que contexto ha ocurrido. > > > Cierto. Por eso la excepción debería contener suficiente información como > para que el manejador adquiera ese conocimiento. > > b) tiene que ser previsto un posible error, y además considerar TODOs > los > errores posibles/relacionados por parte de un objeto que no tomo la > responsabilidad. > > No, de ninguna manera. Nunca se pueden prever todos los errores posibles, > ni tiene sentido hacerlo. para eso hay manejadores por defecto de las > excepciones. Tiene que haber excepciones específicas y relevantes, y el > manejador tomará las que considera que es su responsabilidad y capacidad > atender. Como cualquier objeto. > > y una característica que la hace muy conocida y cómoda para quien no ha > trabajado mucho tiempo en objetos: > c) existe en otros/varios "lenguajes de programación" > > > Básicamente, porque la copiaron de Smalltalk... > > > Hay otros temas, como, por ejemplo: > x.- el mecanismo de excepciones se complica cuando se disparan procesos > paralelos y debe heredarse manejadores de excepciones, etc. > > Seguro, sería una complicación adicional. pero más para la VM y el > administrador de procesos que para el programador. > > x.- el manejo de errores, a veces, quedan en lugares insólitos y no > pueden > ser rehusados fácilmente (sino que debe ser planificado). > > Totalmente en desacuerdo. El manejo de errores tiene que quedar donde hay > información para hacerlo, donde se conoce cuál era la intención de la > operación y hay una lógica posible para la recuperación. > Y si está en el lugar correcto, es parte del comportamiento del objeto y > puede ser reusado (rehusar es negarse) tan fácilmente como el resto. > > > El segundo mecanismo (2) es el más cómodo y apropiado para tu propósito. > Todo error, aunque comience a ser tratado por una excepción; termina > enviando el mensaje #error: a un objeto (a menudo, el objeto que encontró > una condición adversa mientras resolvía una responsabilidad generada por un > envío de mensaje). > > > ----------------------------------------------------------------------------------- > > > Según veo, tus comentarios son contrapuestos a los de Ale y me confunde un > poco. > Que opinión te merece lo que dice Ale ? > > > Espero haberlo dejado claro; estoy de acuerdo en algunas cosas y en > desacuerdo en muchas otras. > De todos modos, te doy una diferencia fundamental: en ese texto, él está > hablando en general y sin un ejemplo concreto. Yo sólo me atengo al caso que > vos trajiste, un pedazo de código en una clase de stream. Tal vez, en este > contexto puntual, su opinión se parezca más a la mía. > Para la discusión más general, te recomiendo de nuevo contactar a Hernán, > tal vez él tenga algo escrito sobre el uso de excepciones (recuerdo haber > visto una clase muy interesante en la materia de la UBA). > > > > > Saludos kiko > > PD: Espero nadie se moleste por poner comentarios de personas que no > participan de esta lista, si es así solo avisen y no lo hago mas > > > No lo sé. A mí me molesta un poco, pero me molestaría más discutirlo en la > lista de Smalltalking. > Saludos > > -- > > carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. > decide smarter.* > > [email protected] <http://mc/[email protected]>| > t: +1.281.598.8790 | t: +54.11.4389.0126 | > www.caesarsystems.com > > **This message and any attached documents contain information from Caesar > Systems LLC that may be confidential/trade secret and/or privileged. If you > are not the intended recipient, you may not read, copy, distribute or use > this information. If you have received this transmission in error, please > notify the sender immediately by telephone or by reply e-mail and then > delete this message. > > -- > To post to this group, send email to > [email protected]<http://mc/[email protected]> > To unsubscribe from this group, send email to > [email protected]<http://mc/compose?to=clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > > > > > -- > To post to this group, send email to > [email protected]<http://mc/[email protected]> > To unsubscribe from this group, send email to > [email protected]<http://mc/compose?to=clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > > > > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
