Newsgroup: it.comp.lang.delphi
Titolo: Domanda peri signori della Borland

....ma anche per i vari "big" (vedi Marco Cantù)
Il Delphi ha una grande limitazione secondo me, e cioè il capire dove 
cavolo si è generato un run time error e perchè.
Spiego... se un cliente mi ritorna un run time error (sempre che poi lo 
abbia segnato da qualche parte) devo
1 ripescare la versione che lo ha generato (primo problema in quanto il 
cliente non la ridà quasi mai)
2 ricompilare tutto
3 ricercare il codice di errore (che poi se è generato da qualche 
libreria sono cavoli)
insomma è un bel casino.
Mi chiedevo dato che la Borland stà acquistando tutti i pacchetti che 
usa e relative società (vedi Caliber) perchè non acquista o crea un 
pacchetto decente per l'individuazione dei run time error o access 
violation che siano?
Nota personale:
Personalmente uso EurekaLog e lo trovo eccezionale (memorizzazione stato 
computer, trace delle linee di codice, possibilità di stampare o inviare 
per e-mail l'errore, eccetera). Creato da un programmatore o Team 
Italiano. Mailing list per eventuali problemi, upgrade gratuiti eccetera 
eccetera.
- lo so è pubblicità gratuita ma se qualcosa piace... piace -

 Personalmente uso EurekaLog e lo trovo eccezionale
uso anch'io EurekaLog e in merito al tuo quesito rispondo che se ci
fosse stato un pacchetto similare integrato con Delphi non avremmo
acquistato EurekaLog, o altri similari quali madException. Quindi se
sei così entusiasta di EurekaLog pensa che non avrebbe potuto
esistere, o magari non l'ho avresti preso in considerazione.
Lo stesso ragionamento vale per tutti i componenti che puoi trovare a
pagamento o non; potrebbe farli la Borland, invece Borland si è
"limitata" a fornire una VCL alquanto vasta dove chiunque può
"lavorarci su".
Ciao

Pienamente daccordo ma la mia domanda era un'altra...
dato che la borland stà acquistando tutti i pacchetti che usa anche 
gratuiti (vedi fastMM) perchè non vuole colmare questa che per me è una 
lacuna ?

[...]perchè non vuole colmare questa che per me è una lacuna ?
Perché è innanzitutto una lacuna dei programmatori :-)
Prima si impari a programmare e poi si critichi il metodo di cattura degli
errori ;-)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


questa risposta centra come i cavoli a merenda. 

 errori ;-)
Critico in quanto credo di saper programmare come si deve ma sono sempre 
umano quindi posso benissimo incappare in errori. Ma perdere una 
settimana (lacuna del cliente o dati insufficenti) a presso ad un errore 
in quanto non ho informazioni che mi diano indicazioni dove esso possa 
essere generato non lo accetto.

 umano quindi posso benissimo incappare in errori. 
Certamente, ma gli errori non sono solo determinati da distrazione umana.
Ci sono condizioni esterne che possono determinare un errore e non è
sempre possibile capire con certezza la sua origine.  I programmatori,
allo stesso tempo, dovrebbero sforzarsi di imparare le tecniche per
gestire gli errori nel migliore dei modi.  Ti assicuro che è
possibilissimo tenere sotto controllo gli errori di distrazione.  Ad
esempio, sono molto pochi i programmatori che scrivono codice secondo un
paradigma "difensivo".  Quante volte hai visto una funzione che testi la
validità dei suoi parametri e, soprattutto, quante volte ne hai vista una
che testi la validità dei suoi risultati?
Quanti sono gli sviluppatori che scrivono suite di test per i propri
sistemi?
Tornando al discorso di partenza, non dubito l'utilità dei tool che hai
citato, ma ne comprendo maggiormente l'utilizzo in contesti (vedi la
programmazione in C, non C++, in cui sei abbastanza scoperto) in cui il
sistema di sviluppo non offra già dei validi supporti alla gestione degli
errori.
