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]> escribió:
De: Carlos E. Ferro <[email protected]>
Asunto: Re: [clubSmalltalk] StdioFileStream dolphin
Para: [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
--
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
