Hola Carlos Perdón por la demora, pero estaba tratando de masticar un poco tu respuesta y mi concepto anterior. 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. 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). 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. ------------------------------------------------------------------------------------- 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. 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. 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" 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. x.- el manejo de errores, a veces, quedan en lugares insólitos y no pueden ser rehusados fácilmente (sino que debe ser planificado). 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 ? 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 --- El jue 29-jul-10, Carlos E. Ferro <[email protected]> escribió: De: Carlos E. Ferro <[email protected]> Asunto: Re: [clubSmalltalk] StdioFileStream dolphin Para: [email protected] Fecha: jueves, 29 de julio de 2010, 9:00 On 28/07/2010 18:24, Jose Gregoris wrote: Hola Carlos Gracias por tus comentarios. Tiene otro problema, la función que usa esta obsoleta, según la pagina de microsoft, que a esta altura se debería llamar macrosoft :). Ah, no me fijé en eso... sólo me quedé en este método. Pero ¡eso está fuera de Smalltalk! Porqué estas diciendo que esta mal usar #error: ? . No recuerdo bien los motivos, pero los mecanismos de control de error no son intercambiables. #error: suele disparar una excepción del tipo más genérico posible, que normalmente no es atrapada ni manejada por nadie, y por default te saca un cartel. Sacar carteles desde un lugar de nivel tan bajo es malo, no tenés idea del contexto de donde fue llamado esto. Por otra parte, la excepción es tan genérica, que perdés un montón de información sobre qué pasó exactamente. Hay que buscar un tipo de excepción específico, algo que sea como FileNotFound, y mandar esa. Así, el sender puede manejarla sin quedar mal. Un "on: Error do:" es grosero, en cambio, poner [ file open ] on; FileNotFound do: [ ... ] suena razonable. Al saber qué error está manejando, se puede hacer algo con sentido en el handler. Saludos -- signature carlos e. ferro | senior developer | caesar systems | see clearly. decide smarter. [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] To unsubscribe from this group, send email to [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
