Newsgroup: it.comp.lang.delphi
Titolo: BDE in remoto

ciao
La mia applicazione esporta dati da una tabella locale ad una tabella remota
(al momento tutte e due le tabelle sono sulla macchina su cui gira
l'applicazione)
Ho compilato ed eseguito, e sulla macchina su cui è stato compilato tutto Ok
Copiata ed incollata identica (anche le tabelle) su un'altra macchina mi da
un'errore sulla connessione
Ho provato con 4 PC
BDE è installato (ovviamente) su tutti i Pc
Qualche idea o problemi simili?
grazie ciao

posta l'errore

 ora dico ... c'č sempre un buon motivo per mettere un try except ;)
Dipende!
Usare il try serve a nascondere l'errore č una cosa che, imho, č errata.
Come gia fatto in altri post precedenti, ribadisco che troverei +ttosto
difficile, in tale sitauzione, fare le seguenti cose:
1) rispondere ad un cliente che per telefono mi segnala un errore. Se non ho
un messaggio o un codice di errore, da cosa parto per dargli indicazioni?
2) come faccio a verificare se una app funziona se nascondo i messaggi di
eccezione?
Magari, sarebbe piů giusto:
1) evitare i path statici nelle applicazioni in quanto, vedi questo caso,
non č detto che il cliente usa la app nel ns stesso path di lavoro
2) aggiungere un controllo di esistenza dei files esterni necessari al
funzionamento della applicazione, che segnala cose del tipo "attenzione:
file c:\x\y.z non trovato!'
Bye
A.

 non è detto che il cliente usa la app nel ns stesso path di lavoro


Usare il try serve a nascondere l'errore 
No, usare il try significa *gestire* l'errore, è una cosa MOLTO
diversa. Inoltre il try si può usare, semplicemente, per stabilire che
un certo insieme di operazioni debbano essere eseguite sicuramente,
anche quando le cose vanno storte (vedi try/finally) senza impedire
alle eccezioni di sollevarsi (tipicamente questo è l'approccio che si
usa nelle funzioni, in cui la gestione di errori, eventualmente
occorsi, si lascia al chiamante).  Altro uso (meno comune, ma valido)
del try/except è quello di catturare l'eccezione, agire di conseguenza
e risollevarla.  Diciamo che non si dovrebbe mai usare un try/except
con un corpo "except" vuoto (specie se il debug dell'IDE è
disabilitato) ma ci sono casi in cui questo tipo di uso è valido ed
innocuo.
-- 
Andrea Laforgia
"God is dead." -- Nietzsche
"Nietzsche is dead." -- God

mtInformation) e con un messaggio
Fai benissimo, però alzerei il livello di guardia.  Io per esempio,
gli errori generamente li gestisco con dei "mtWarning" e non degli
inquietanti "mtError".


"Andrea Laforgia" <x@x.x> ha scritto nel messaggio
news:eio75v8jod38j9v2d...@4ax.com...


 diversa.
Sorry! Mi sono espresso male.
Intendevo dire cio che hai detto tu, e cioè che si dovrebbe in linea di
massima evitare un blocco except vuoto.
Condivido il try..finally che uso molto nel mio codice, ad esempio nel
classico caso in cui li usa la sequenza per essere sicuri di liberare
eventuali risorse allocate.
Bye
A.

 per rendere piů solidi i metodi delle mie classi
il try..finally ok.
Ma, come diceva ANdrea, un blocco excpet vuoto non rende il tutto + solido,
anzi!
Diciamo che corrisponde al mettere la testa sotto la sabbia x non vedere....
;))
Bye
A.

 Chi deve capire sei TU.
Sono d'accordo. Tanto, per l'utente, sempre di errore si tratta.
Grave o meno grave, non sta a lui determinarlo.
--
Jax
Journeying Artificial Xenomorph

via email...
Ciao Alberto!
Volevo dire che seguendo il thread mi e' venuto in mente di quando ho sviluppato
per un istituto di credito a milano: avevo letto degli studi interi su come
presentare gli errori, quali colori, quali icone, quali avvisi....
Ma sopratutto *cosa* mostrare: noi avevamo costruito un oggetto che mostrava un messaggio
di errore che non causasse uno stato di agitazione ( esattamente come dice laforgia evitando
di utilizzare "inquietanti" mtError), ma che mostrasse, alla pressione del bottone 
"visualizza errore", la verbosita' dell'errore.
Trattandosi di software finanziario, questo visualizzava poi l'abend del db2: cosa
incomprensibile ad un funzionario, ma chiarissimo al programmatore di turno.
Mi sembra interessante, quindi, fare il punto della discussione e isolare quelli che
potrebbero essere i "topos" di una buona interfaccia errore.
1- non utilizzare colori violenti (tipo mega-finestrone rosso fuoco "ERRORE GRAVE!!!INDICI CORROTTI")
2- non utilizzare messaggi forti,negativi ("grave","irreversibile","perso","rovinato")
3- mascherare la verbosita' tecnica dell'errore (magari dando la possibilita' di visualizzarla in seconda battuta)
4- non minacciare di licenziamento l'utente ;-)
Ciao!
--
Morde. 
morde[at]programmer[.]net

Grave o meno grave, non sta a lui determinarlo.
E dei messaggi spia? Ne sai qualcosa? 
12 anni fa, su un'applicazione, avevo fatto una personalizzazione
per un cliente che sospettavamo copiasse il nostro software.
Ora, il programma funzionava perfettamente, solo che quando si accorgeva
di risiedere su una macchina dal bios diverso di quello rilevato
nell'installazione, presentava un errore del tipo "hard disk gravemente
danneggiato". Davanti ad un messaggio ansiogeno come quello, il cliente
piratone si attacco' al telefono chiamandoci... e facendosi scoprire.
(A quei tempi si lavorava con il dos e per copiare un programma 
bastava copiarne la directory)
Ciao 


 bastava copiarne la directory)
Non che adesso sia molto diverso :))


 pressione del bottone "visualizza errore", la verbosita' dell'errore.
Non posso che essere d'accordo. (oggi non so dire altro) :)
