Newsgroup: it.comp.lang.delphi
Titolo: Delphi è sempre in vita

Ciao,
  per diversi progetti ho sviluppato in delphi poi ho svolto altre attività 
e da due anni non ho sviluppato nulla di nuovo.
  Delphi è vivo e vegeto o vivacchia?
  Mi sono domandato questo perchè ne sento sempre parlare meno e perchè due 
riviste a cui ero abbonato su delphi hanno chiuso.
  Stanno passando tutti a .NET o Java?
Luca 

   Stanno passando tutti a .NET o Java?
Anche Delphi è passato a .NET con Delphi 8. Tuttavia, l'elevato prezzo 
di Delphi se comparato con Visual Studio (dello stesso livello 
ovviamente) e il fatto che gli oggetti fra Delphi e VS sono gli stessi 
(perché basati entrambi su .NET) ha probabilmente spinto molti ad 
abbandonare Delphi e migrare a VS che, come ho detto, ad un prezzo più 
basso fornisce molti più linguaggi e strumenti (oltre che un enorme 
comunità di supporto).
Ciao,
   Luca

"Luca" ha scritto nel messaggio

Magari non è solo un tentativo di scatenare un flame?
Gianluca.

 Stanno passando tutti a .NET o Java?
Anche con Delphi puoi passare a .NET (se ti occorre). :-)
Personalmente, rimango in attesa di verificare le caratteristiche di 
Delphi 9 (Diamondback), la versione di prossima uscita che riunisce 
Win32 e .NET in un unico ambiente con nuove feature previste per il 
primo compilatore citato (sostanzialmente, quanto di nuovo è stato 
introdotto in Delphi .NET ma utilizzabile nella piattaforma Win32).
Per qualche "rumor" a riguardo:
http://homepages.borland.com/mswindell/2004/08/diamondback-rumors.html
La comunità Delphi è sempre viva e vegeta! ;-)
Ciao! :-)
-- 
Marco «Alka» Breveglieri
  ABLS Team S.n.c. - Software & Web
  Via De Gasperi, 14
  42019 Scandiano (Reggio Emilia)
 
http://www.abls.it

> Magari non č solo un tentativo di scatenare un flame?
Sě, lo credo anche io. Che io sappia non esistono molte riviste su
Delphi, le uniche che conosco sono indicate a questo link e sembrano
ancora vive e vegete ;-)
http://delphi.about.com/cs/magazines/tp/aatpmagazines.htm
Ciao
Antonio

 ancora vive e vegete ;-)
Si, praticamente sono talmente poche che costituiscono un mercato di nicchia
e quasi non riescono nemmeno a farsi concorrenza.
Comunque, a livello piu' generale, conviene diffidare da chi entra per la
prima volta in un newsgroup tecnico senza aver mai postato messaggi tecnici
e "si presenta" con il classico quesito di "cosa è meglio" o con un post
chiaramente polemico del tipo "nessuno lo usa piu'". E questo in genere vale
per Delphi VS [Visual Basic, .NET, Java, ...], Windows VS Linux, Laureati VS
Diplomati, Dipendenti VS Liberi Professionisti/Imprenditori, Cani VS Gatti,
Cucina tradizionale VS Fast Food, Pizza VS Spaghetti, Bionde VS More, Star
Trek Prima Serie VS Star Trek Next Generation,  ... ...
Ciao,
Gianluca.

 ancora vive e vegete ;-)
Ero abbonato a "DelphiZine", decisamente ottimo. Anche "The Delphi 
Magazine", leggendo gli articoli di esempio sul sito e su una copia 
promozionale non č affatto male, molto interessante.
Eccellenti riviste...ma hanno un tale costo! :-)


 chiaramente polemico del tipo "nessuno lo usa piu'".
Sinceramente, hai fatto bene a farmelo notare, perchè inizialmente non 
ci avevo pensato. :-)
Tra l'altro, siamo stati già avvertiti qualche giorno fa da un apposito 
(quanto insignificante) MANIFESTO. :-)
Ciao!


 linguaggi e strumenti (oltre che un enorme comunità di supporto).
Sapevo della nuova versione se .NET ma al di la de costo (importante ma non 
unica scelta) è sembre più flessibile Delphi o VS è più o meno equiparabile? 
Se costa di più ma è stabile e non devo ricorrere a continui aggiornamenti 
perchè non dovrei usarlo, sempre che non costi il doppio.
Ciao 


Assolutamente no, sviluppavo in D6 e visto che tra poco devo iniziare una 
nuova avventura devo scegliere la piattaforma o VS o Delphi.
Quindi è lecito chiedere, oltre tutto Delphi lo conosco e VS no.
Ciao 


Vero ma non č aggiornata.
Tratto dal sito Delphi Informant Magazine
http://www.delphizine.com/
The August 2004 issue of Delphi Informant Magazine will be the last issue. 
Your subscription will be replaced with a subscription to our other 
publication, asp.netPRO
Ciao 

 La comunità Delphi è sempre viva e vegeta! ;-)
Sono altro che felice, so dove chiedere quando ho qualche problema.
Grazie 

ci avevo pensato. :-)
Ma perche' tanta malfidenza? ;-)
Non vedo particolari toni provocatori o allusivi nel post dell'OP.
In fin dei conti questo si sara' letto google groups le varie ridde di flames
che abbondano in quest'ultimo anno su .net, e si sara' fatto delle domande
lecite.
E mi sembra giusto fornirgli le risposte che cerca, nei limiti della nostra
esperienza sul campo. :-)
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

  Stanno passando tutti a .NET o Java?
Cosa facciano le riviste non te lo so dire, di fatto Borland stessa con delphi
8 è passata su .net.
Ciao


 Eccellenti riviste...ma hanno un tale costo! :-)
io invece ero abbonato a The Delphi Magazine ma proprio questo
settembre non ho rinnovato l'abbonamento. :( Non è una questione di
costi, perché come hai fatto notare la qualità è davvero elevata,
quanto per il fatto che necessariamente stanno spostando gli argomenti
quasi completamente su .NET, quindi per me che ancora ne so poco,
diventava una spesa inutile.
Ciao
Antonio

 nuova avventura devo scegliere la piattaforma o VS o Delphi.
Sono nella tua stessa identica situazione. ;-)
In azienda stiamo avviando un nuovo progetto e, da un "brainstorming" 
interno, pare che il .NET Framework sia la piattaforma più adatta a 
sostenerlo. Ovviamente, è una scelta che riguarda il progetto nello 
specifico e non può essere assolutamente valida per tutti i progetti.
Si pone davvero il problema di quale ambiente di sviluppo adottare (e la 
parola "adottare" è proprio azzeccatissima)... :-)
A complicare la scelta subentra il fatto che sono in uscita due prodotti 
concorrenti, Delphi 9 e Visual Studio 2005, dei quali non ho ancora 
chiare quali saranno le feature nella loro totalità, perciò ho deciso - 
per il momento - di acquisire nozioni sull'architettura del framework in 
generale e di realizzare dei prototipi in attesa che vengano presentate 
le caratteristiche dei principali ambienti di sviluppo di prossima 
distribuzione.
In merito ad un suggerimento da darti, l'uso del .NET Framework o no 
dovrebbe essere valutato in base alle caratteristiche del prodotto che 
ti stai accingendo a sviluppare (se questo è il tuo dubbio).
Se non hai necessità "cross language" (come invece le ho io adesso), 
puoi comunque sviluppare in Delphi 7 e sfruttare le conoscenze già 
acquisite che dici di avere sull'ambiente Borland e, con un occhio di 
riguardo, effettuare il porting a .NET se e solo se diverrà strettamente 
necessario, magari appoggiandoti alla libreria VCL .NET.
Che tu scelga di sviluppare su .NET oppure no, una particolare 
attenzione al framework - secondo me - è necessaria per aumentare le 
probabilità di una maggiore longevità dell'applicazione.
A parte questo, se decidi di utilizzare .NET, io attenderei comunque 
l'uscita di D9 e VS2005, cercando un confronto tecnico che vada al di là 
del prezzo, incentrato sulla valutazione del "cosa è meglio per me?". :-)
Personalmente, spero che Delphi 9 mi dia valide argomentazioni per 
votare "Borland" alla prossima riunione aziendale. ;-)


 Ma perche' tanta malfidenza? ;-)
Hai ragione e devo chiedere scusa all'OP, ma sai...dopo tanti "flame" a 
cui ho contribuito attivamente...... o mio Dio, sono un TROLL! :-D


 diventava una spesa inutile.
Accidenti, io avrei fatto proprio la scelta contraria, sai? :-)
Insomma, non avrei disdetto un abbonamento proprio quando cominciavano 
pubblicazioni di un argomento che non conosco... :-D
Scherzi a parte, hai ragione se la trattazione si riferiva alle classi 
della FCL (Framework Class Library) di Microsoft, dato che pagare 
(profumatamente) una rivista per ottenere informazioni su una libreria 
che non usi non è molto logico; se la trattazione riguardava invece il 
linguaggio in se, forse hai fatto male dato che le feature introdotte 
per Delphi .NET saranno presenti anche nel compilatore Win32. :-)
Ciao!


 perchè non dovrei usarlo, sempre che non costi il doppio.
Mi dispiace, non ti so dare maggiori informazioni in merito. D8 non mi 
piace per nulla quindi l'ho abbandonato al suo destino.
Considera che essendo sia D8 che 
VS.NET
 basati su .NET usano i medesimi 
oggetti (a meno che tu non voglia usare la 
VCL.NET
, ossia un porting 
della VCL su .NET) quindi una volta che li hai imparati puoi usare 
indifferentemente D8 o uno dei linguaggi di 
VS.NET
.
Persino il loro IDE è simile oramai.
Secondo il mio modesto parere oramai l'unica cosa che differenzia D8 da 
VS.NET
 è il fatto che in D8 programmi in pascal (o meglio... un pascal 
modificato per .NET [in cui per esempio anche i numeri sono oggetti a 
loro volta]).
Dopo queste considerazioni io sono giunto alla conclusione che tanto 
valeva impararsi VS invece (
VB.NET
 o C#) visto che il costo 
dell'ambiente è leggermente inferiore ma soprattutto per la vastissima 
comunità.
Delphi mi piaceva proprio perché era un prodotto alternativo e diverso 
dai prodotti (secondo me di bassa lega) della M$. Delphi mi piaceva 
anche per il fatto di creare EXE a sé stanti, senza dovermi preoccupare 
di installare decine di DLL sui PC su cui i miei software dovevano 
girare (come invece accadeva in VB per esempio).
Oramai, imo, si equivalgono troppo e tutti i vantaggi che Delphi aveva 
per me si sono vaporizzati.
L'unica rogna è cambiare linguaggio... ma visto che mi devo reimparare 
tutti gli oggetti .NET tanto vale passare qualche ora in più ed 
impararmi un linguaggio nuovo.
Ciao,
   Luca

 nuova avventura devo scegliere la piattaforma o VS o Delphi.
Allora mi scuso per il mio essere sempre così "sospettoso".
A mio avviso il tuo dubbio dovrebbe essere "spaccato" in due:
1 - sviluppare in Win32 o sviluppare in .Net?
2 - nell'ambito dello svilupppo in .Net, utilizzare Delphi o passare ad
altro?
La risposta dipende un pò dal tipo di progetto, dalle dimensioni, dalla
compatibilità, dai tempi, se si tratta di nuovo progetto o riconversione di
progetto già esistente... ovvero è difficile trovare una soluzione che elimi
tutti i dubbi.
Per quanto mi riguarda, ho riconvertito un'applicazione in C# ed è stato un
vero e proprio bagno di sangue (vuoi l'inesperienza, vuoi qualunque altro
mio limite). Alla fine ho accettato il compromesso ed ho deciso per una
soluzione mista dove alcune parti sono sviluppate in Delphi 6.0 ed altre in
C#.
Questo perchè per certe problematiche usare .Net sembra di sparare una
cannonata su un formicaio. Solo lo stesso ADO .Net con la sua logica
completamente disconnessa crea un tale livello di astrazione dal database
che, se da una parte è ottimo perchè risolve una serie di problematiche in
ambito C/S o di elaborazione distribuita, in realtà rende molto piu'
complicato sviluppare la classica applicazione desktop che accede a una o
piu' tabelle.
In sostanza direi che .Net è ottimo per progetti "enterprise" di una certa
dimensione, mentre in talune situazione è veramente "troppo grosso".
Se poi .Net diventa la soluzione (obbligo o scelta) resta da definire quale
linguaggio utilizzare. Anche qui dipende dal problema. Dovendo sviluppare "a
nuovo" io passerei a C#. Semplicemente perchè è il linguaggio principe di
.Net e si ha la garanzia di poter sviluppare per qualunque implementazione
del Framework.
Dovendo convertire un'applicazione già esistente, forse passerei a Delphi
per ottimizzare i tempi. Per quel poco che ho visto di questo ambiente, mi
sembra sia eccessivamente lento e "mastodontico" addirittura rispetto al
Framework. Ottimo il lavoro fatto per mantenere la compatibilità con il
passato, ma a questo punto c'è troppa astrazione rispetto a quelle che sono
le caratteristiche del Framework.
Io ad oggi, a parte questa applicazione sviluppata in C#, resto saldamente
ancorato a Delphi 6.0
Ciao,
Gianluca.
-- 
Gianluca Plevani
-----------------------------------------------------------
http://www.brain-enterprise.com

 del Framework.
sottoscrivo e aggiungo che come linguaggio non è male.
AS

 le caratteristiche del Framework.
Non capisco questa frase...
Ciao! :-)


 sottoscrivo e aggiungo che come linguaggio non è male.
Lo preferirei comunque a 
VB.NET
, che non riesco a digerire nemmeno 
quando osservo banali esempi di codice... :-P


 clientdataset+datasetprovider (midas).
In realtà ADO .Net è sempre disconnesso.
Il Dataset è una rappresentazione dei dati (del database) residente in
memoria. Esso è *sempre* disconnesso dalla sorgente dati e sa da dove
vengano. In questo definisci vari DataTable, per ogni DataTable hai i
DataColumn, i DataRelation, ecc. Insomma tutto ciò che avresti a livello di
un qualsiasi DBMS, ma solo in memoria. Quando effettui il Fill con una
sorgente dati tramite il DataAdapter, ti ritrovi il Dataset contenente i
dati. Quindi poi con la relazione sui controlli visuali diventa tutto ok.
Come saprai la modifica dei dati avviene in memoria finchè effettivamente
questi non vengono inviati nuovamente al database. Nel mio caso ho delle
DataGrid e le modifiche fatte ad un record per motivi vari devono
*immediatamente* essere rilasciate nell'archivio. In questa situazione, per
evitare di appesantire troppo l'elaborazione con dei continui Update per un
solo record modificato, ho dovuto scrivermi degli oggetti che fungessero da
sorgente dati e che "impacchettassero" tutto il codice di insert/update del
singolo record elaborato. Una gran differenza rispetto al quasi "codice
zero" necessario in Delphi.
Questo nel mio caso, ovvero una applicazione desktop. Nulla toglie che in
situazioni di elaborazione distribuita o di semplice client/server, la
logica disconnessa fornisce una rilevante ottimizzazione del traffico e
delle prestazioni in generale.
Un altro problema è stato soprattutto "psicologico". A me non piace affatto
dover sviluppare "con il libro", dovendo continuamente interrompere per
rivedere se ho ben capito come si fa una certa cosa o perchè mi sono
dimenticato qualche funzionalità. Essendo nuovo del framework questo è
normalissimo, ma a tutti gli effetti in certe situazioni è molto limitante.
Ultimo, ma non ultimo, sviluppare con il fiato sul collo di una nuova
versione del framework (ed in particolare dell'ambiente Visual Studio 2005
ormai alle porte) che potrebbe introdurre molte novità (ad esempio sembra
che ritorni il concetto di recordset), pesa perchè senti di sviluppare
qualcosa di "già obsoleto". Quest'ultima è però una considerazione del tutto
personale: lavoro con Delphi 3.0, Delphi 5.0 e Delphi 6.0 e non mi sento
obsoleto perchè sò che quando avrò modo e tempo (ed i componenti adatti)
potrò con poco sforzo passare alla versione che più mi aggrada. La mia
esperienza con Microsoft (varie versioni di Visual Basic) invece è sempre
stata caratterizzata da una certa "paura" di dover ricominciare da capo con
concetti del tutto consolidati. E non credo di esserci andato molto lontano.
Gianluca.

 zero" necessario in Delphi.
Non ho ben compreso ciò che dovevi fare di preciso, quindi è possibile 
che mi sbagli ma...forse non hai utilizzato gli strumenti giusti?
P.S.: se si va un po' OT...ditemelo... :-)
Ciao!


P.S.: se si va un po' OT...ditemelo... :-)
Parlatene,parlatene... siamo IT, e questo e' forse il primo thread su .net
dove si parla di programmazione reale.


 un linguaggio nuovo.
Sembra di sentire quello che pensavo quando ho scritto qui. Non vorrei 
passare ad ambiente MS ma se la direzione è quella un pensiero ce lo faccio. 
La cosa che mi scoccia è imparare qualcosa di nuovo dato che non tutto 
questo tempo da spendere.
:( 

 esperienza sul campo. :-)
Grazie, ero titubante della cosa perché mi aspettavo una reazione del 
genere.
Semplicemente qualche domanda per evitare di pentirmi in futuro. D6 lo 
conosco abbastanza bene, VB6 la conosco così ma visto l'orientamento di 
molti verso .NET o Java le domande ci stavano.
Ho cercato su Google un po' ma nulla di concreto e perchè non postare la 
domanda qui.
Speravo che Delphi 9 uscisse a breve per vedere come si comporta e se è 
soprattutto meglio di MS. Se non ricordo male domani inizia la Borland 
Conference e preannunciano un po' di novità anche per Delphi.
Ciao 

 diventava una spesa inutile.
Vedi sopra.
Luca 

 "Borland" alla prossima riunione aziendale. ;-)
Mi associo.
Luca 

 Win32. :-)
I primi articoli su .NET riguardavano un pò entrambe le cose, anche se
le caratteristiche del linguaggio, IMHO, sono più semplici da imparare
e la complessità vera è data dall'intero framework.
Nel penultimo numero di TDM, 8 articoli per .NET, 1 che riguardava la
migrazione win32 -> .NET ed un solo articolo Win32. Ho scritto
all'editore, il quale mi ha anche rassicurato sulla presenza di
articoli win32 anche s egli risultava difficile convincere gli autori a
scrivere ancora per win32 con .NET alle porte, ma la mia decisione ad
oggi è stata questa.
Quando mi deciderò a studiare .NET comprerò il collection CD di TDM che
costa 30 sterline e che consiglio davvero a tutti, in quanto contiene
tutti i numeri pubblicati da questa splendida rivista, e farò ripartire
l'abbonamento ;-)
Ciao
Antonio

 la versione successiva. :-)
Penso che questo suggerimento sia sensato. Meglio aspettare D9 e 
decidere poi.
Ciao,
   Luca

 poi.
Sono fiducioso di quello che presenteranno in questi giorni al BC.
http://info.borland.com/conf2004/tracks/product/delphi.html
Luca 

 questi giorni facciano saggiare qualche feature.
Indipendentemente dalle feature che avrà D9, la migrazione di progetti 
D7 verso .NET è già possibile; al massimo, spero che tale portabilità 
sia facilitata nel nuovo ambiente.
Lo sapremo tra qualche giorno... ;-)


 > il C++,
ops... errore di sbaglio: intendevo C#.

Beh.... ho anche messo in dubbio l'uso degli strumenti. Mi sono basato piu'
che altro sull'ausilio di un collega che con .Net ha già una certa
esperienza ed ovviamente ho abbondantemente arricchito la mia libreria.
Il problema sta alla base: ho un'applicazione in Delphi di circa 20.000
righe di codice di cui almeno l'80% è tutta gestione del ciclo produttivo di
un impianto, del colloquio con gli strumenti via porte seriali ed
elaborazione dei dati mentre il resto praticamente è inserito negli eventi
di gestione dei vari OnValidate, BeforPost, BeforeDelete, ecc. degli
archivi.
Per quanto riguarda l'interfaccia utente, praticamente sono una decine di
maschere. Tutte DataGrid direttamente connesse a tabelle Paradox locali.
Oltre qualche consultazione e report da un'altra applicazione in rete.
Il progetto di passaggio a .Net originariamente comportava l'utilizzo di
MSDE locale e la riscrittura di tutta l'applicazione in C#.
Ovviamente il DataReader è connesso, però dal momento in cui devi presentare
i dati in una interfaccia utente, se usi il DataReader, devi popolare
manualmente la griglia ed inoltre intercettare tutti gli eventi di
spostamento per poi usare un'altro DataReader per effettuare la query di
INSERT o UPDATE sul record appena modificato. Oppure, naturalmente, passare
attraverso apposite classi che fungano da sorgente dati per la griglia in
questione. Ma il codice in questione è molto di piu' rispetto a quello da
fare in Delphi. Questo perchè ho la necessità che la modifica appena
effettuata dall'utente sia immediatamente rilasciata sul database.
A quanto mi risulta, con ADO .Net essendo sempre disconnesso, utilizzando
gli strumenti DataSet e DataAdapter (manuali alla mano) le modifiche vengono
rilasciate con l'Update. Ci pensa poi il DataAdapter ad eseguire i vari
Command di inserimento, eliminazione ed aggiornamento. Quindi in questa
logica per ogni record modificato nella griglia avrei dovuto chiamare
l'Update con un certo dispendio di elaborazione (se valutiamo che è
necessario per un solo record) oppure scrivermi apposite classi che
potessero fare da sorgente dati per l'interfaccia utente e gestissero record
per record dando l'impressione di essere connessi (che è quello che abbiamo
fatto).
Un'altra soluzione poteva essere l'utilizzo delle librerie ADO tradizionali
ma mi è stato altamente sconsigliato in quanto trattandosi di oggetti COM
vengono gestiti in modalità unmanaged attraverso un proxy interop
assembly... credo.
Quindi, tutto 'sto codice scritto solo per mantenere allineata l'interfaccia
utente, rispetto al concetto semplicissimo TDBGrid <-> TDataSource <->
TAdoTable (con gestione degli eventi di TAdoTable per quanto relativo le
validazioni) a me è sembrato veramente eccessivo. Questo parlando di Visual
Studio 2003 nudo e crudo. Ovviamente con componenti aggiuntivi, si può far
di tutto... ma il budget è quello che è.
Una nota sulla gestione delle eccezioni (parlando sempre di C#). Da una
parte ho trovato molto interessante il poter gestire il concetto di
InnerException, ovvero mi posso creare una "lista" di eccezioni dove ogni
livello di elaborazione fino ad arrivare al gestore, inserisce la propria.
Dall'altra parte però non mi piace come vengono trattate in assenza del
gestore. In Delphi se l'eccezione viene sollevata all'interno di un evento
resta isolata allo stesso. Infatti io faccio molto uso delle eccezioni per
avvertire l'Utente. Le preferisco in quanto il codice mi sembra piu' pulito
senza necessità di costruire nidificazioni di funzioni che restituiscono
true/false. In C# se non gestisci esplicitamente un'eccezione ti ritrovi
fuori dall'applicazione, e la cosa non mi piace affatto. Inoltre mi è anche
stato che le eccezioni sono dispendiose per il Framework e quindi sarebbe
bene non usarle O_O (!!!???) in sostituzione di funzioni che restituiscono
true/false in relazione al risultato dell'elaborazione.
Gianluca.

Chiedo scusa: mi è "sfuggito" il messaggio prima che finissi di "ripulirlo"
dal quoting vario.  :-)
Gianluca.

Gianluca.
	Ciao
	MassimoB
 
---------------------------
http://www.massimobeschi.it/

Visto che siamo in tema e stiamo andando un pņ a ruota libera. Una nota piu'
che positiva al Compact Framework. Ho fatto delle prove e sviluppato delle
piccole utilitą per PocketPC e sono rimasto pienamente soddisfatto. Niente
di particolare: due programmini per il calcolo del seriale di una mia
applicazione, ed una calcolatrice di conversione binario <-> esadecimale <->
decimale (per vedere al volo lo stato della memoria delle aree di memoria
del PLC senza passare dalla calcolatrice di Windows).
Il codice č riutilizzabile praticamente al 100% e la stessa applicazione ora
funziona sia sul mio PC che sul Palmare.
Inoltre mi ha fatto molto piacere poter effettuare il rilascio
dell'applicazione sul palmare e poterne fare il debug direttamente
dall'ambiente Visual Studio installato sul PC. Magari ero io ad essere un pņ
"indietro", ma complessivamente mi ha molto colpito questa possibilitą.
Gianluca.

 risultato dell'elaborazione.
Non comprendo bene le basi tecniche di questo presupposto; a mio avviso, 
l'uso delle eccezioni è uno dei modi più puliti di gestire gli errori e 
sono state introdotte soprattutto per sostituire obsolete forme di 
controllo degli errori che si basavano, come nelle API di Windows, su 
valori di ritorno delle funzioni chiamate che, puntualmente, venivano 
ignorati o, per i programmatori fedeli all'etica, richiedevano righe e 
righe di codice per controllare, ad ogni chiamata, la presenza di una 
condizione d'errore, intavolando poi degli statement *case* o *switch* 
che altro non facevano che complicare inutilmente il codice.
Sia in C# che in Java, l'uso delle eccezioni viene promosso, anche se 
almeno C# non incorpora le "checked exception" come Java, cioè la 
necessità di dichiarare tutte le possibili eccezioni che un metodo può 
generare (le quali dovranno essere necessariamente gestite all'esterno 
di tale metodo, effettuando la chiamata in un blocco di codice protetto).
Ciao! :-)


> Lo sapremo tra qualche giorno... ;-)
http://blogs.borland.com/johnk/archive/2004/09/13/1306.aspx
 

 
http://blogs.borland.com/johnk/archive/2004/09/13/1306.aspx
 
Sto seguendo anche io l'evolversi delle vicende. Le premesse mi paiono 
buone...staremo a vedere. :-)
