Hola,

Aunque entendiendo por dónde quieres ir, si no estoy equivocado, no puedo estar de acuerdo contigo en que el cierre de una instrucción, esto es, el punto y coma sea una tontería.

Prueba de ello es el aviso del compilador, más allá, prueba de ello es que el compilador no continuará adelante hasta que no se solucione "esa tontería".

¿Alguien puede explicarme qué es un programa diseñado para tontos? ¡No conozco ninguno! Si no es un programa "malicioso", que busca la ingenuidad del usuario o su carencia de conocimientos, para vete a saber qué.

Cualquier programa está pensado para alguien y aun alguienes. Y se presupone a ese alguien la capacidad de entender lo que quiere hacer. Porque un programa puede ser al mismo tiempo una herramienta: el usuario habrá de saber qué quiere hacer con ella.

Si PhotoShop, por poner un caso, fuera un programa hecho para tontos hasta yo podría hacer lindas imágenes, pero esto no es así: prueba de que PhotoShop no es un programa para tontos.

Vale. Podría hacer cualquier cosa que pareciera una imagen, pero todos sabemos lo que da de sí un programa como PhotoShop y ni por pienso sabría yo hacer algo como lo que por ejemplo estoy recordando ahora.

Delphi no es un programa para tontos. ¿O sí? Yo diría que no. Pero es un programa. Yo tengo entre manos un programa ahora y no lo estoy haciendo para tontos, puedo prometerlo. Porque no sabría cómo hacerlo, aunque quisiera.

Los asistentes para Windows (cualquiera de ellos) no están hechos para tontos. Simplifican, esconden, "hacen cosas". Si el usuario no quiere ir más allá yo no creo que sea tonto, es que simplemente no necesita más. ¿Para qué darle lo que no necesita? No es tonto: sabe lo que quiere.

Es verdad que no siempre. lamentablemente.

En todo caso creo que esto sería para debatirse, en el sentido de que seguramente aún no tenemos claro lo que el uno piensa que piensa el otro (por lo menos yo me incluyo en esa cuenta) y así será cuestión de dejar claro que, pase lo que pase, esto no pasaría nunca a mayores.

¡Pero yo no hago programas para tontos, que conste! ;)

try except
 

Lo que dice roman es correcto, sin seguir hablando de lo mismo, eso tiene que ser asi: LOS PROGRAMAS TIENEN QUE SER HECHOS PARA TONTOS...
es increible, las malas intepretaciones que puede tener la gente de las cosas!
yo basicamente utilizo mucho los try/except y siempre tenes q usar plan b,, muchas veces un aviso,, SIEMPRE, siempre los uso..

Saludos!

Me parece que el asunto se aclara muy facil. En parte, estoy de acuerdo que las personas tienen mucho potencial, y tratarlas de forma despectiva no es lo mejor. Por otro lado, el que una persona tenga un PHd en Ingenieria quantica-nuclear de plataformas intelesterales biologicamente interconexas, no lo hace *necesariamente* capacitado para usar DOS y darle dir *.* ;) Si esta persona no conoce el programa/sistema se vera tan tonto como nosotros tratando de definir que es la fisica quantica....

Me parece que podriamos extractar varias lecciones:

1- Ocultar complejidad: Bueno. Si voy al medico necesito que me responda : "Nene, tenes como una fiebre altisima, ve!. Por si te preguntan tenes una bacteria amorfa, llamada niMeAcuerdoComoSeLlama piluris bla bla, pero en fin, a la camita y mucha naranja!". Es mejor "El archivo Tata.tutu no se encuentra" a lo que sea que diga el compilador/OS.

2- Evitar/Corregir el problema: Bueno. Como dice DEC, que saque un mensaje de error por SIMPLEMENTE seleccionar un item en una lista, no solo es (ahi si) tonto, sino que deberia tomarse como una ofensa capital! Es responsabilidad de la persona con la mejor informacion y mas cercana a la solucion (o sea nosotros) manejar el asunto.

3- Ignorar/Ocultar informacion: MALO. El asunto es que hay NIVELES a la hora de dar informacion... Debe saber el usuario FINAL TODO el mensaje de error, con call stack, version del compilador, mensaje de excepcion, direccion del servidor, etc??? (gracias, dira el hacker!!!) Normalmente, no. Debe saber todos y cada uno de los errores que saca el programa? Indiscutiblemente NO.

Pero lo que le puede interesar al ADMINISTRADOR del sistema/red, es muy diferente. Y lo que necesita saber el PROGRAMADOR es mucho mas. Es por eso que unas cosas deben sacar mensaje de error, escandalosamente (= TODO LO QUE NO ESPERABAMOS) otras debe ser mensajes agradables (= LO QUE EL USUARIO ESPERARIA QUE SE LE INFORMARA, ie: Que el archivo no se encontro donde se le dijo) otras deben quedar en un log (para el personal tecnico) y tal vez el resto solo se debe ver en una version del ejecutable/exe ESPECIAL para depuracion, con los assert activados, con una estrategia AGRESIVA de logeo de mensaje y sin nada que enmascare el problema (desactivando los mensajes lindos, por ejemplo). Esto si que le salva la vida cuando se requiere...

4- Dar una respuesta general a una pregunta especifica: MALO. Si ya sabemos que va a sacar un mensaje a la hora de convertir el numero de caracteres a integer, porque poner un un manejo general de la excepcion? SI YA SABEMOS QUE VA A PASAR, pues digamoselo al compilador! Y de esa manera, el codigo queda explicito: Si pones EConvertError el proximo programador vera la intencion de la excepcion de forma clara.

Pero, ¿quién habló de tratarlas de forma despectiva? Lo dicho. Cuando el compilador me saca a mí un mensaje diciéndome que falta un punto y coma no me siento tratado despectivamente. Por el contrario, si el compilador, o cualquier otro programa me avisa rápida y oportunamente de un dato mal ingresado, por tonto que sea, más bien me siento agradecido.

// Saludos

Yo si. :D :D :p ;)

No me referia a sacar los mensajes (o no), sino a la actitud que uno tiene hacia los demas (en este caso los usuarios o clientes).



Cuando uno considera que estos son "tontos", la imagen que se tiene afecta de una u otra manera la forma en como hacemos las cosas. Otra cosa es reconocer que las personas, incluso las que en teoria son inteligentes, puedan hacer cosas tontas de vez en cuando.

Y a veces, realmente hacemos que nuestros usarios actuen de forma muy tonta. Un concepto que lei, y es que una manera de hacer que la gente (=usuarios) sean un poco menos miserables (osea mas felices!) es darle una sensacion de control...

Este articulo de Joel (español) me gusto mucho:

http://spanish.joelonsoftware.com/ui...hapters/1.html

Es sobre como hacer interfaces de usuario, por ejemplo, si estoy haciendo algo tonto, pero no recibo, de alguna manera, indicacion de ello, entonces me voy a sentir infeliz.

Para un usuario (generalmente), los programas deberian de ser como la experiencia de un buen carro: Excelente suspencion, frena cuando se le dice, pita si se le va a acabar la gasonlina, etc... Para un programador, debe ser como manejar un avion: Lucecitas y pitidos por todos lados, porque el grado de posibles errores es mayor...



Los mensajes de error y la manera como se manejan las excepciones pueden ayudar o desfavorecer el grado de control de un usuario sobre el programa. Para un programador, se necesita los mensajes mas constantemente, mas visiblemente y mas informativamente. Realmente me frustra que me saque el Delphi un Exeption at addres 0x8.... que no me dice nada, pero es peor que no lo haga...



Los mensajes de error pueden dar mas control, bien usados.





"El archivo tutu.tata no existe" Ok, esta bien, eso lo puedo manejar, si algo, le pregunto al que sabe de sistemas: Estoy en control.



El programa se cierra sin avisar! Eso si es frustrante, no se que hacer (hice algo mal? Que?) El windows tiene un virus! A correr el antivirus. Listo. Nada. Desfragmentar? Ok. Vuelvo al programa, hago lo mismo. Se cierra. Formateo? Pregunto, no me dicen nada... arrghhhh!!!!!



"El formato de la fecha es incorrecto" Ok, no sabia que las fechas tenian formato: Llamo a soporte tecnico y me dicen que hago. Estoy en control.



La fecha se ingreso, sin verificar. Los saldos contables NO CUADRAN!. Me equivoque? Reviso todas mis transacciones. ESTAN BIEN! Reviso otra vez?? El jefe me hecha la culpa! LLamo a soporte tecnico (sinceramente no sabran todavia)...


En fin. Es la idea... Volviendo a la actitud: Muy estupido pensar que el defragmentar CORRIGE un problema-En serio hay usuarios que luego de hablar con tantos tecnicos piensan que la ruta a la solucion es: Antivirus, Degramentar, reinstalar- Pero que se le va a hacer: Como puede saber que paso? Sin un mensaje de error, asi sea un Exception address at 0x8000 que saque DENTRO del programa, todo se puede pensar... Es por eso que volviendo al temas: Los errores no se pueden ocultar. Solo se debe filtrar la cantidad, frequencia y alarma de los mismos, es nuestra responsabilidad. Y si no hay tiempo para hacer eso: No enmascarar los errores. Al menos los errores escandalosos permiten tener un grado, aunque pequeño, de control, un camino mas probable de solucion...

Creo entonces, que estamos totalmente de acuerdo. En mi opinión las aplicaciones deben estar hechas a prueba de tontos pero sin que esto signifique tratar al usuario como tal. Me parece muy atinada tu observación referente a la sensación de control, y esto aplica a toda la interfaz en general. Una aplicación puede ser muy buena pero si no se diseña la interfaz pensando en el usuario final- quien es el que tendrá que lidiar con ella día con día -gran parte de su valor se pierde. A no ser que no haya otra opción, yo, como usuario, generalmente escojo aplicaciones potentes pero que de entrada den la sensación (y lo sean) de ser fáciles de usar.

// Saludos

Ayuda con Try...Except
 

Hola estoy tratando de hacer un programita que me escanee la red y que me borre el documents and settings de las maquinas encontradas. Mas o menos he logrado parte de esto, pero me da error cuando trata de borrar al usuario que esta logueado y algunos otros. Quisiera saber de que forma se puede evitar estos errores para que el programa no se detenga y continue borrando. Es decir como se usaria el try...except aqui.

:confused::eek::D:D:D:D:D jejeje


¿cuanto tardarán? :rolleyes:

sevilla19742
 

¿Te imaginas qué pasaría si en un código de apenas unas cuantas líneas, el compilador no tuviera a bien decirnos: "Missing operator or semicolon" ¿Es obvio que los parámetros de una función deben ir separados por comas!
sevilla19742