Problema de las terminales globales - página 5

 
WHRoeder:
ProfessorMetal: No soy uno de los neófitos
Sin comprobación de errores, no estoy tan seguro.
ProfesorMetal: no intentes enseñar al abuelo a chupar huevos, tío. Tranquilo, hijo.
WHRoeder: No tienes tiempo para hacerlo bien a la primera, pero sí para hacerlo de nuevo, o para rastrear los errores causados por él.
Tienes que relajarte. Te estás poniendo en plancha por una simple observación. Y no me llames "hijo", soy mayor que tú (1957).

"Sin comprobación de errores, no estoy tan seguro" Este es exactamente el tipo de comentario al que me refiero. Está fuera de lugar.

No tengo ningún problema presonal contigo, Roeder. Me tomé lo que dijiste como un ataque inmerecido. Mis disculpas si he entendido mal tu intención. Por cierto, el uso del término "Hijo" es común en mi país. Es como decir "Hombre" o "Amigo" o lo que sea.

Cuando hablo de que el manejo de errores es caro, lo hago desde el punto de vista de estar acostumbrado al paradigma try/catch de Microsoft. Eso requiere muchos recursos y consume mucho tiempo en lo que respecta al tiempo de ejecución. La práctica aceptada es la arquitectura de su aplicación, determinar dónde es probable que surjan los problemas y luego añadir su manejo de excepciones. No hay que abusar de ello, especialmente en una aplicación en tiempo real. Eso es tan malo, si no peor, que no hacer ningún manejo de excepciones. Si te refieres a usar condicionales para comprobar errores, entonces, sí, lo hago como algo natural.

En cuanto a la situación particular que estoy encontrando cuando el depurador se bloquea no parece haber inicializado nada en absoluto. El depurador muestra un gráfico durante una fracción de segundo y muere. Según el registro, carga los indicadores, etc. y luego los descarga inmediatamente. En el indie en el que estoy trabajando actualmente tengo alertas en OnInit() para saber si no está intentando inicializar el indie. Veo el mismo tipo de comportamiento si ejecuto el depurador en otros indies que sé que no tienen problemas. No estoy del todo seguro de lo que está pasando pero al final lo averiguaré. Como dije en un post anterior, la documentación es incorrecta en cuanto a donde dice que se encuentra debug.tpl. El directorio ni siquiera existe en la instalación de MT4. O la documentación es incorrecta o la implementación de MT4 tiene problemas. Así que, en este momento, estoy pensando que es 50/50 en cuanto a si estoy arruinando de alguna manera o algo está mal en la implementación de la plataforma.

En cualquier caso, acordemos que nos hemos entendido mal, nos damos la mano y seguimos adelante. No hay necesidad de una batalla entre nosotros. ¿Guay?

 
angevoyageur:

Puedo sugerir a nuestros programadores veteranos que dejen este tipo de discusión aquí.

Gracias.


Estoy de acuerdo. Esto es completamente contraproducente - y poco profesional.
 
ProfesorMetal. No podría estar más de acuerdo con usted en sus opiniones sobre el manejo excesivo de errores y la preferencia por las pruebas hacia adelante.
 
gatoreyefx:
ProfesorMetal. No podría estar más de acuerdo con usted en sus opiniones sobre el manejo excesivo de errores y la preferencia por las pruebas hacia adelante.

Gracias. Encantado de conocerle. La experiencia es un gran maestro. :-)
 
  • ProfessorMetal:

    Gracias. Encantado de conocerte. La experiencia es un gran maestro. :-)

    No creo que sea una buena recomendación aquí, ya que la mayoría de los miembros son principiantes o codificadores aficionados, y uno de los problemas más recurrentes proviene de la falta de comprobación de errores. Además, los codificadores experimentados no necesitan tales recomendaciones, ya que tienen su propia experiencia y hábitos.
 
Estoy de acuerdo con angevoyageur, la gestión de errores reduce el tiempo dedicado a la depuración y/o a pedir a otros que ayuden a encontrar la causa de los problemas.
 
Bueno, desde que se actualizó desde la build 509, he estado usando el manejo de errores. Ahora, casi ninguno desde que he eliminado de la ea que estoy seguro de que el código son lo suficientemente estables para manejar los errores. Algo así.
 
angevoyageur:
  • ProfesorMetal:

    Gracias. Encantado de conocerle. La experiencia es una gran maestra. :-)

    No creo que sea una buena recomendación aquí, ya que la mayoría de los miembros son principiantes o codificadores amateurs, y uno de los problemas más recurrentes proviene de la falta de comprobación de errores. Además, los codificadores experimentados no necesitan tales recomendaciones, ya que tienen su propia experiencia y hábitos.


Tienes un punto válido con respecto a los codificadores principiantes y amateurs. No pretendía defender que nadie siguiera mi enfoque. Simplemente quería aclarar el qué y el por qué. He dicho que "la experiencia es un gran maestro" :-)

Por cierto, creo que tu última afirmación es algo que estaba tratando de transmitir a Roeder, junto con el hecho de que hacer que tus interacciones con otros miembros del foro consistan principalmente en atacar y menospreciar a la gente no sirve para nada más que para masajear tu propio ego. Los que tenemos experiencia deberíamos responder a los menos experimentados que realmente lo intentan con respeto y consideración, no con burla. Con esto, considero el asunto cerrado. He dado una respuesta conciliadora a William. Si él quiere aceptarla, está bien. Si no, también está bien.

 
SDC:
Estoy de acuerdo con angevoyageur, la gestión de errores reduce el tiempo dedicado a la depuración y/o a pedir a otros que ayuden a encontrar la causa del problema(s).


No discuto eso de ninguna manera. Mi punto, realmente, era que los desarrolladores experimentados ganan una "sensación", si quieres llamarlo así, de dónde es probable que surjan los problemas. Por ejemplo, si tengo un método que requiere parámetros, siempre compruebo que son los que deberían ser antes de intentar ejecutar cualquier código. Es un hábito automático desarrollado a partir de años de trabajo en aplicaciones industriales en las que un método va a ser llamado por otros desarrolladores que trabajan en otra parte de la aplicación o directamente por los usuarios finales si se trata de un elemento de la interfaz de usuario. Rápidamente aprendes a no confiar en que alguien te va a enviar lo que se supone que debe hacer.

La mayor parte de lo que estaba hablando era el paradigma try/catch. Eso no es un problema con MQL porque, hasta donde yo sé, MQL no tiene el manejo de excepciones que emplea Microsoft. Eso hace que una gran parte de lo que dije discutible.

Que conste que el problema parece no haber sido con ninguno de mis indies. No creí que lo fuera pero siempre es posible, nadie es perfecto, yo menos. Utilizo un EA gratuito de gestión de operaciones de terceros porque no he tenido tiempo de desarrollar uno propio. Para probar ideas usando cuentas demo lo considero suficientemente bueno. Supongo que obtienes lo que pagas - es un freebie. Me deshice de él y el depurador no se ha estrellado desde entonces. Sin embargo, todavía hay algunos problemas.

Lo que dije antes sobre la desconexión entre la documentación y el funcionamiento sigue vigente. No hay ningún directorio de perfiles/plantillas en la instalación de MT4. Además, la documentación no le dice nada sobre cómo configurar y utilizar las plantillas de depuración. He pasado bastantes horas jugando con las cosas para ver cuál es el comportamiento actual en MT4. Lo que he llegado a compartir en algún lugar, pero no estoy seguro exactamente donde la etiqueta del foro dictaría. En este hilo aislado es probablemente un no, a menos que uno de los Mods que están monitoreando esto piensan que sí. ¿Debería crear un nuevo hilo, entregar mis observaciones a un Mod para que pueda crear una etiqueta adhesiva o debería simplemente compilar todo y dispararlo al Servicio de Atención al Cliente yo mismo? Lo que los Mods piensen es la dirección que tomaré.

 

No creo que haya una carpeta de perfiles/plantillas. Mi carpeta de plantillas está en la carpeta de datos del terminal.