Newsgroup: it.comp.lang.delphi
Titolo: Sqrt - non TRAPpabili

Non capisco perchè lanciando l'EXEguibile (di cui allego il cui sorgente)  
si verificano alcune anomalie rispetto a quanto accade 'dentro' Delphi':
1) La velocità nel primo caso è molto superiore...
2) Premendo il pulsante più volte appare il messaggio 'Floating
point error'.. ma se le eccezioni sono intrappolate (--> avviene fuori) !?.
Sistema : D4 cs+patch3, K6 350 no overclock, 64Mb, WinSoz95-OSR2+AMD Patch.
procedure TForm1.Button1Click(Sender: TObject);
var
R,J  : real;
begin
  R := 0;
  While R < 10000 Do
  begin
    Try  J := Sqrt(-R);
    Except end;             
    R := R+1;
  end;
end;
Grazie anticipatamente !
--
:-) )-: ... ;-) (-:

 end;
ciao
--
(¯`·.¸¸.·´¯`·.¸¸.-> Andrea <-.¸¸.·´¯`·.¸¸.·´¯)
AntiSpam: rimuovere il trattino basso dall'indirizzo per rispondere
AntiSpam: remove the underscore from the e-mail address to reply




 point error'.. ma se le eccezioni sono intrappolate (--> avviene fuori)
!?.
In quale dei due casi si verifica questo: all'interno di delphi o fuori?
Se avviene all'interno di delphi allora la cosa si può capire, altrimenti
no.

Spero che questo sia solo un programma dimostrativo ;-)
Anche col 'Do' l'errore si verifica comunque. 
Except  on EMathError do Sleep(1)  end; C-)
Se puoi provare la sorgente , compilarla e lanciare il project1.exe, ti sarei
grato se me ne comunicassi l'esito .
tnx.

no.
Avviene nell'exe , in delphi no problem .
ciao.
--
Trombetta,Trombetta,...questo nome non mi e' nuovo !


La ON...DO non e' indispensabile nel costrutto TRY/EXCEPT.
Se si omette, tutto cio' che e' contenuto fra except ed end viene eseguito
quando avviene l'eccezione.
Volevo pero' dire che anche io ho notato degli strani funzionamenti in
Delphi con le eccezioni, sebbene non sono ancora sicuro al 100% che non si
tratti di un mio errore. Il fatto e' questo:
try
    pIInterfacciaCheMiServe := pIIunknown as IInterfacciaCheMiServe;
    {Eseguo "altre azioni")
    .....
    .....
finally
    { Parte di finalizzazione comune }
end;
Lo scopo del codice e' quello di non far eseguire il blocco "altre azioni"
se l'oggetto puntato da pIIunknown non implementa l'interfaccia
IInterfacciaCheMiServe, senza pero' far apparire all'utente il dialogo di
errore "interface not known" o roba del genere.
La funzione che contiene il codice e' in una DLL, che viene richiamata, nel
caso specifico, da un programma scritto in C++ Builder.
Ebbene, l'eccezione non viene "trappata", causando la terminazione
anticipata della procedura, con ritorno al loop messaggi primario
Se invece io scrivo:
try
    pIInterfacciaCheMiServe := pIIunknown as IInterfacciaCheMiServe;
except
    pIInterfacciaCheMiServe := nil;
end;
if( Assigned(pIInterfacciaCheMiServe) ) then
begin
    {Eseguo "altre azioni")
    .....
    .....
end;
tutto funziona correttamente. L'eccezione viene catturata ed il codice viene
saltato.
Qualche idea Andrea?
Ciao,
Stefano

anticipata della procedura, con ritorno al loop messaggi primario
Che io sappia le eccezioni non vengono gestite molto bene nelle DLL (ho gia'
avuto varie esperienze in proposito, dovendo lavorare spessissimo con alcune
DLL fatte in Delphi o C++ Builder). Anzi, direi che funzionano abbastanza
male, infatti tante volte ottengo un "errore di pagina non valida" anche
solo per una conversione sbagliata, o una (lo so, non dovrebbe accadere)
divisione per zero. Di solito Delphi, se non ci sono TRY-EXCEPT esce dalla
routine in casi come questo, ma con la DLL a volte mi si pianta tutto anche
se ci sono!
Le librerie dinamiche sono delle brutte bestie... =)
Ciao
Daigo

 anticipata della procedura, con ritorno al loop messaggi primario
Ciao Stefano,
                        il codice che scrivi mi sembra più che corretto
quindi la cosa mi lascia un po' perplesso...
Mi frulla in testa l'idea che sia COM a metterti i bastoni fra le ruote:
quando "as" chiama la Query Interface di IUnknown non so a che livello lo
faccia ma può essere che il sistema intervenga di forza ritornando il
controllo al loop di messaggi. Dubito che c'entri troppo il fatto che il
codice stia in una DLL: sostanzialmente le cose non dovrebbero cambiare se
fosse in un EXE.
Sarebbe interessante fare dei confronti: con che versione di Delphi compili?
Ciao :-)


 anticipata della procedura, con ritorno al loop messaggi primario
Finally non intercetta l'eccezione, ma permette di eseguire un pezzo di 
codice anche se il codice tra il try..finally genera delle eccezioni.
Il comportamento di delphi è corretto.
Devi usare try..except per intercettare l'eccezione e impedire che si 
propaghi.
-- 
Roberto Lupi


Il problema l'ho riscontrato sia in Delphi 4 che in Delphi 5, mentre
l'eseguibile e' scritto in C++ Builder 4
Ciao,
Stefano

 Il comportamento di delphi è corretto.
In generale sì, nel caso citato no...
Tra l'altro il problema era che il codice "salta" alla coda di messaggi
uscendo direttamente dalla procedura mentre dovrebbe al massimo uscire dal
blocco try...finally...


 Il problema potrebbe anche essere relativo all'abbinata C++Builder/Delphi
Mai sperimentata quindi non mi pronuncio...


anticipata della procedura, con ritorno al loop messaggi primario
Si, comunque ciò è conforme a quanto riportato nell'Help di D4:
If an exception is raised (invalid Typecasting nel tuo caso) during 
execution of statementList1, control is transferred to statementList2;
once statementList2 finishes executing, the exception is ... RE-RAISED.
Quindi Finally ti garantisce solo l'esecuzione di Statementlist2 in ogni
caso (cioè sia che si verifichi o meno l'errore in statementlist1).
-  try statementList1 finally statementList2 end -
Ciao!


Cosi' si evince leggendo la guida.
Pero' a me pare che in alcuni casi non propaghi l'eccezione.
Faccio delle prove, magari sono dei casi particolari
Ciao,
Stefano

anticipata della procedura, con ritorno al loop messaggi primario
Si, cmq ciň č conforme a quanto riportato nell'Help di D4:
If an exception is raised (invalid Typecasting nel tuo caso) during 
execution of statementList1, control is transferred to statementList2;
once statementList2 finishes executing, the exception is ... RE-RAISED.
Quindi Finally ti garantisce solo l'esecuzione di Statementlist2 in ogni
caso (cioč sia che si verifichi o meno l'errore in statementlist1).
-  try statementList1 finally statementList2 end -
Ciao!
--
Vox dei in dubio audire oportet !

 blocco try...finally...
Alla fine del blocco try..finally l'eccezione č effetivamente segnalata 
di nuovo, quindi il codice successivo al blocco try..finally non viene 
eseguito (sempre che non sia un altro blocco try..finally o try..except).
-- 
Roberto Lupi

 statements nell'help).
Comincio a pensare che tu e Golem abbiate perfettamente ragione... ;-)
Ciao
