Re: [clubSmalltalk] StdioFileStream dolphin

[Carlos E. Ferro]

Title: signature

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. cefe...@caesarsystems.com | 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 clubSmalltalk@googlegroups.com To unsubscribe from this group, send email to clubsmalltalk+unsubscr...@googlegroups.com   http://www.clubSmalltalk.org