StdioFileStream dolphin

De: Carlos E. Ferro <[hidden email]>
Asunto: Re: [clubSmalltalk] StdioFileStream dolphin
Para: [hidden email]
Fecha: miércoles, 28 de julio de 2010, 12:03

On 28/07/2010 11:44, Jose Gregoris wrote:

Hola En la clase StdioFileStream tenes el mensaje  : StdioFileStream >>read: aString text: aBoolean

    [ . . . ]

No es mejor que primero verifique la existencia del archivo y luego proceda ? Es un error de codificación o estoy errado ?

Estás errado.
No es UN error de codificación. ¡Son varios!

Probablemente alguien "mejoró" el método en CRTLibrary y ahora se traga la excepción y te devuelve nil.
Ya es feo que el comment sea tan largo. Aparentemente, hay mucho para entender en un método que es muy corto...
y no se entiende leyendo el código. Eso es mala señal (aunque entiendo que puede ocurrir en lugares "puente" donde invocás una función externa).
Es malo que te diga que levanta una excepción, si en este método no se levanta ni se maneja.
Eso quiere decir que el que lo escribió conoce la implementación de lo que está llamando, y sabe que va a tirar una excepción. El problema es que conocía la implementación de ese momento... el comentario y su valiosa info quedan obsoletos en cuanto alguien modifica en otro lado.

Otro problema que oscurece el método es el argumento en la expresión anidada de paréntesis.
Nosotros aplicamos siempre la "regla de Valloud" en estos casos (perdón, Andrés, pero está en el libro):
un argumento de un keyword no puede ir nunca entre paréntesis. Requiere un nombre que aclare qué es.
Finalmente, los nombres de los argumentos no aportan suficiente información, que ya tenemos y agiliza la lectura.
Rápidamente lo reescribiría así:

StdioFileStream >>read: filename text: aBoolean
    "Access is character based or binary, depending on the <boolean> argument"

    | handler mode |

    mode := aBoolean ifTrue: ['rt'] ifFalse: ['rb'].
    handler := CRTLibrary default fopen: filename mode: mode.
    handler isNil ifTrue: [ self error: 'File ', filename, ' does not exist' ].
  ^self basicNew
        setStream: handler
        isText: aBoolean
        name: filename

Ojo, donde puse self error:, eso también es muy malo; ahí hay que generar una excepción apropiada.

Saludos

--

carlos e. ferro | senior developer |  caesar systems | see clearly. decide smarter.

ceferro@... | 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

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

--

carlos e. ferro | senior developer |  caesar systems | see clearly. decide smarter.

ceferro@... | 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

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

ceferro@... | 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

De: Guillermo Sapaya <[hidden email]>
Asunto: Re: [clubSmalltalk] StdioFileStream dolphin
Para: [hidden email]
Fecha: martes, 3 de agosto de 2010, 15:18

>     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) ?

Me sumo a la lista de los admiradores de Kikote!
Quizás por cosas como estas muchos no te contestamos :-)

Salud!
Guiye

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...

http://www.clubSmalltalk.org

De: GallegO <[hidden email]>
Asunto: Re: [clubSmalltalk] StdioFileStream dolphin
Para: [hidden email]
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 <kikodelphi@...> 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 <ceferro@...> escribió: De: Carlos E. Ferro <ceferro@...> Asunto: Re: [clubSmalltalk] StdioFileStream dolphin Para: clubsmalltalk@... 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. ceferro@... | 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@... To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...   http://www.clubSmalltalk.org

 

--
To post to this group, send email to clubSmalltalk@...
To unsubscribe from this group, send email to clubSmalltalk+unsubscribe@...
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

De: Carlos E. Ferro <[hidden email]>
Asunto: Re: [clubSmalltalk] StdioFileStream dolphin
Para: [hidden email]
Fecha: martes, 3 de agosto de 2010, 16:13

On 03/08/2010 15:08, Jose Gregoris wrote:

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"

Es que ESA pregunta... Para decirte cómo uso ST, tengo que condensarte un montón de cosas y realmente, no me da para hacerlo en un email. Tendría que escribir un libro, como Andrés... Hay un montón de detalles, que son los que hacen a cómo realmente lo uso. Si te contesto con líneas generales, voy a hablar en el aire y no te voy a decir nada realmente interesante.

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í.

Que con el manejo de procesos en paralelo, seguro se agrega un nivel de complejidad. Pero no es un nivel de complejidad del que deba preocuparse el que programa la excepción ni el que programa su manejo. Esa complejidad queda en otro lado. O al menos, eso creo.  Habría que ver un ejemplo concreto.

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) ?

A que Alejandro muchas veces escribe rehusar, no sé si a propósito o no, para lo que otra gente llama reusar (que sería como re-usar, usar más de una vez, en más de un contexto). Pero en castellano, ese verbo existe y tiene un significado preciso, bien definido. Es negarse a algo.

Saludos

--

carlos e. ferro | senior developer |  caesar systems | see clearly. decide smarter.

ceferro@... | 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

De: Carlos E. Ferro <[hidden email]>
Asunto: Re: [clubSmalltalk] StdioFileStream dolphin
Para: [hidden email]
Fecha: jueves, 5 de agosto de 2010, 12:08

On 04/08/2010 16:36, Jose Gregoris wrote:

Hola Carlos Es que ESA pregunta... Para decirte cómo uso ST, tengo que condensarte un montón de cosas y realmente, no me da para hacerlo en un email. Tendría que escribir un libro, como Andrés... Hay un montón de detalles, que son los que hacen a cómo realmente lo uso. Si te contesto con líneas generales, voy a hablar en el aire y no te voy a decir nada realmente interesante. No pretendo tanto, solo que me digas por ejemplo que metodologias  usas para desarrollar:  TDD, BDD, Par Programing. Si usas UML o diagramas de algun estilo , etc.

Igual, esto solo a es largo... pero va:
A grandes rasgos, usamos algo parecido a XP. Pero tenemos un workflow y un montón de prácticas que son particulares de esta organización y difíciles de transportar.
Lo más fuerte es que TODO se revisa. No sólo el código y los cambios que hace cada uno, también los documentos que escribimos, las tareas administrativas, los power points que se van a mostrar en algún lado.. todo.
Y la revisión es autoría colectiva. El revisor modifica libremente y el autor no se ofende ni se pelea, nadie se encariña con sus ideas. Todo se discute, pero separando lo que es gusto de lo que es objetivo.

Para el bug fixing, programamos de manera individual, muchas veces hacemos TDD.
Para el desarrollo de cosas nuevas (User Stories) , hacemos discusiones en grupo y ahí hacemos algún diagrama, pero sólo para ese momento y no quedan en ningún lado. También hacemos documentos de especificación a nivel que el usuario pueda validar, sin exponer cómo se implementa. En general, las tasks las hacemos con pair programming.

Saludos

--

carlos e. ferro | senior developer |  caesar systems | see clearly. decide smarter.

ceferro@... | 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org