Grazie alka.Originariamente inviato da alka
Delphi, C#, VB.NET, Java e tanti altri...![]()
![]()
Grazie alka.Originariamente inviato da alka
Delphi, C#, VB.NET, Java e tanti altri...![]()
![]()
Giorgio
L'esperienza è il tipo di insegnante più difficile. Prima ti fa l'esame, e poi ti spiega la lezione. (Oscar Wilde)
Sì ... avevo capito ... ma questa e' "l'incognita del mestiere".Originariamente inviato da giorgiogio48
Ciao oregon,
a parte il mio scherzo che visto ora mi sembra fuori posto, il probema è non è progettare una applicazione che non intercetti gli errori, ma far si che non vi esistano errori commessi dallo sviluppatore. E' questa la mia difficoltà. Ora come ora l'applicazione sembra funzionare bene, ma quando ci sono troppe routine è difficile rendersi conto che qualche sezione di codice non va.
Ciao e grazie ancora.
E' praticamente impossibile, almeno in progetti complessi, essere certi di non aver commesso errori "logici", che magari saltano fuori solo in determinate condizioni di flusso del codice.
Le eccezioni aiutano ma non risolvono tutto.
Giusta precisazione. Cioè, alla luce di una possibile incomprensione, va indicato che le eccezioni sono solo un valido meccanismo per gestire errori a runtime, ma è ben diverso rispetto alla correzione di errori logici.Originariamente inviato da oregon
Le eccezioni aiutano ma non risolvono tutto.
Voglio dire, se il programma deve sommare "a + b" e invece somma "a + b + c", non vi è alcun errore a runtime ma solo un errore logico in quanto lo sviluppatore non ha codificato correttamente il programma, producendo comunque codice corretto. Non esiste un sistema in grado di conoscere, leggendo nella mente, lo scopo dello sviluppatore, benché vi siano approcci più sensati per limitare la probabilità di bug, ma direi che è impossibile evitarli, poiché...errare è umano.
Ciao!![]()
MARCO BREVEGLIERI
Software and Web Developer, Teacher and Consultant
Home | Blog | Delphi Podcast | Twitch | Altro...