Problema dei terminali globali - pagina 5

 
WHRoeder:
ProfessorMetal: Non sono uno dei neofiti idioti
Senza controllo degli errori, non sono così sicuro.
ProfessorMetal: non cercare di insegnare al nonno come succhiare le uova, amico. Calmati, figliolo.
WHRoeder: Non hai il tempo di farlo bene la prima volta, ma hai il tempo di rifarlo, o di rintracciare i bug causati da esso.
Hai bisogno di rilassarti. Ti stai agitando per una semplice osservazione. E non chiamarmi "figlio", sono più vecchio di te (1957).

"Questo è esattamente il tipo di commento di cui sto parlando. Questo è fuori luogo.

Non ho un problema presonale con te, Roeder. Ho preso quello che hai detto come se mi stessi sbattendo immeritatamente. Le mie scuse se ho frainteso il tuo intento. BTW, usare il termine "Figlio" è comune dalle mie parti. È come dire "Uomo" o "Amico" o qualsiasi altra cosa.

Quando parlo di come la gestione degli errori sia costosa, vengo dal punto di vista di chi è abituato al paradigma try/catch di Microsoft. Questo è molto dispendioso in termini di risorse e di tempo per quanto riguarda il tempo di esecuzione. La pratica accettata è quella di progettare la vostra applicazione, determinare dove è probabile che sorgano problemi e poi aggiungere la vostra gestione delle eccezioni. Non volete usarlo troppo, specialmente in un'applicazione in tempo reale. Questo è altrettanto male, se non peggio, che non fare alcuna gestione delle eccezioni. Se stai parlando di usare i condizionali per controllare gli errori, allora sì, lo faccio come una cosa ovvia.

Per quanto riguarda la particolare situazione che sto incontrando quando il debugger si blocca, non sembra aver inizializzato nulla. Il debugger fa apparire un grafico per una frazione di secondo e muore. Secondo il log, carica gli indicatori, ecc. e poi li scarica immediatamente. Nell'indie su cui sto attualmente lavorando ho degli avvisi in OnInit() in modo da sapere se sta cercando di inizializzare l'indie. Vedo lo stesso tipo di comportamento se eseguo il debugger su altri indie che so che non hanno problemi. Non sono del tutto sicuro di cosa stia succedendo, ma alla fine lo capirò. Come ho detto in un post precedente, la documentazione non è corretta per quanto riguarda dove dice che si trova debug.tpl. La directory non esiste nemmeno nell'installazione di MT4. O la documentazione è sbagliata o l'implementazione di MT4 ha dei problemi. Quindi, al momento, sto pensando che è 50/50 se sto sbagliando in qualche modo o qualcosa è sbagliato nell'implementazione della piattaforma.

In ogni caso, concordiamo sul fatto che ci siamo fraintesi, ci stringiamo la mano e andiamo avanti. Non c'è bisogno di una battaglia tra di noi. Fico?

 
angevoyageur:

Posso suggerire ai nostri programmatori veterani di fermare questo tipo di discussione qui.

Grazie.


Sono d'accordo. Questo è completamente controproducente - e non professionale.
 
ProfessorMetal. Non potrei essere più d'accordo con te sulle tue opinioni sull'eccessiva gestione degli errori e sulla preferenza per i test in avanti.
 
gatoreyefx:
ProfessorMetal. Non potrei essere più d'accordo con te sulle tue opinioni sull'eccessiva gestione degli errori e sulla preferenza per i test in avanti.

Grazie. Lieto di fare la tua conoscenza. L'esperienza è una grande maestra :-)
 
  • ProfessorMetal:

    Grazie. Lieto di fare la tua conoscenza. L'esperienza è una grande maestra :-)

    Non penso che sia una buona raccomandazione qui, dato che la maggior parte dei membri sono principianti o codificatori dilettanti, e uno dei problemi più ricorrenti deriva dalla mancanza di controllo degli errori. Inoltre, i codificatori sperimentati non hanno bisogno di tali raccomandazioni in quanto hanno la loro esperienza e le loro abitudini.
 
Sono d'accordo con angevoyageur, la gestione degli errori riduce il tempo speso per il debug e/o per chiedere ad altri di aiutare a trovare la causa del problema.
 
Bene, da quando ho fatto l'aggiornamento dalla build 509, ho usato la gestione degli errori. Ora, quasi nessuno da quando ho rimosso dal ea che sono sicuramente sapere il codice sono abbastanza stabile per gestire gli errori. Qualcosa del genere.
 
angevoyageur:
  • ProfessorMetal:

    Grazie. Piacere di fare la tua conoscenza. L'esperienza è una grande maestra :-)

    Non penso che sia una buona raccomandazione qui, dato che la maggior parte dei membri sono principianti o codificatori dilettanti, e uno dei problemi più ricorrenti deriva dalla mancanza di controllo degli errori. Inoltre, i codificatori sperimentati non hanno bisogno di tali raccomandazioni in quanto hanno la loro esperienza e le loro abitudini.


Hai un punto valido per quanto riguarda i codificatori principianti e dilettanti. Non avevo intenzione di sostenere che qualcuno segua il mio approccio. Volevo semplicemente chiarire il cosa e il perché. Ho detto che "l'esperienza è una grande maestra" :-)

BTW, penso che la tua ultima affermazione sia qualcosa che stavo cercando di far passare a Roeder - insieme al punto che far consistere le tue interazioni con gli altri membri del forum principalmente nell'attaccare e buttare giù le persone non serve a niente se non a massaggiare il tuo ego. Quelli di noi che sono esperti dovrebbero rispondere ai meno esperti che stanno effettivamente provando con rispetto e considerazione, non con derisione. Con questo, considero la questione chiusa. Ho dato una risposta conciliante a William. Se vuole accettarla, va bene. Se non lo fa, va bene lo stesso.

 
SDC:
Sono d'accordo con angevoyageur, la gestione degli errori riduce il tempo speso per il debug e/o per chiedere ad altri di aiutare a trovare la causa del problema.


Non lo contesto in alcun modo. Il mio punto, in realtà, era che gli sviluppatori esperti guadagnano una "sensazione", se volete chiamarla così, di dove è probabile che sorgano i problemi. Per esempio, se ho un metodo che richiede parametri, controllo sempre che siano quelli che dovrebbero essere prima di tentare di eseguire qualsiasi codice. È un'abitudine automatica sviluppata da anni di lavoro su applicazioni industriali dove un metodo sta per essere chiamato da altri sviluppatori che lavorano su un'altra parte dell'applicazione o direttamente dagli utenti finali se si tratta di un elemento dell'interfaccia utente. Impari rapidamente a non dare per scontato che qualcuno ti mandi quello che dovrebbe.

La maggior parte di ciò di cui parlavo era il paradigma try/catch. Questo è un non-problema con MQL perché, per quanto ne so, MQL non ha la gestione delle eccezioni che Microsoft impiega. Questo rende irrilevante gran parte di ciò che ho detto.

Per la cronaca, il problema non sembra essere stato con nessuno dei miei indies. Non pensavo che lo fosse, ma è sempre possibile - nessuno è perfetto, io meno di tutti. Uso un EA freebie di terze parti per la gestione del trading perché non ho avuto il tempo di svilupparne uno mio. Per testare le idee usando conti demo ho ritenuto che fosse abbastanza buono. Immagino che si ottiene ciò per cui si paga - è un freebie. Me ne sono sbarazzato e da allora il debugger non si è più bloccato. Ci sono ancora alcuni problemi, però.

Quello che ho detto prima sullo scollamento tra la documentazione e il funzionamento vale ancora. Non c'è una directory profiles/templates nell'installazione di MT4. Inoltre, la documentazione non ti dice un bel niente su come impostare e utilizzare i modelli di debug. Ho passato un bel po' di ore a giocare con le cose per vedere qual è il comportamento attuale in MT4. Quello che ho trovato dovrebbe essere condiviso da qualche parte, ma non sono sicuro esattamente dove l'etichetta del forum lo imporrebbe. In questo thread isolato è probabilmente un no a meno che uno dei mod che stanno monitorando questo pensiero. Dovrei creare un nuovo thread, consegnare le mie osservazioni a un mod in modo che possano creare un adesivo o dovrei semplicemente compilare tutto e spararlo al Service Desk io stesso? Qualunque cosa pensino i mod è la direzione che prenderò.

 

Non credo che ci sia mai stata una cartella profiles/templates. La mia cartella templates è nella cartella dei dati del terminale.