Eccezioni o no?

Diatriba sull’uso delle eccezioni tra Miguel de Icaza e Brad Abrams. Ovviamente (basta leggere i miei articoli!) sono a favore delle eccezioni. Alle considerazioni di Brad aggiungo che Miguel sbaglia a considerare la gestione delle eccezioni così costosa. Prima di tutto, è sbagliato vedere un programma pieno di try/catch (mentre dovremmo trovare tante try/finally); inoltre, anche se è vero che usare le eccezioni ha un costo rispetto a non usarle, non è detto che il costo del non-uso delle eccezioni sia migliore: ogni controllo (preventivo sui parametri o successivo sui codici di ritorno) ha un costo, e le eccezioni consentono di ridurre il numero di controlli con un rapporto superiore di 1:1. Attenzione, non voglio dire che l’osservazione di Miguel sia sbagliata: in linea teorica può avere ragione (in particolare quando ragioniamo su API a basso livello), ma se poi qualcuno applica il suo ragionamento a occhi chiusi, senza fare delle considerazioni sul programma specifico che sta realizzando, i risultati sono senz’altro pessimi.

Eccezioni o no?

Diatriba sull’uso delle eccezioni tra Miguel de Icaza e Brad Abrams. Ovviamente (basta leggere i miei articoli!) sono a favore delle eccezioni. Alle considerazioni di Brad aggiungo che Miguel sbaglia a considerare la gestione delle eccezioni così costosa. Prima di tutto, è sbagliato vedere un programma pieno di try/catch (mentre dovremmo trovare tante try/finally); inoltre, anche se è vero che usare le eccezioni ha un costo rispetto a non usarle, non è detto che il costo del non-uso delle eccezioni sia migliore: ogni controllo (preventivo sui parametri o successivo sui codici di ritorno) ha un costo, e le eccezioni consentono di ridurre il numero di controlli con un rapporto superiore di 1:1. Attenzione, non voglio dire che l’osservazione di Miguel sia sbagliata: in linea teorica può avere ragione (in particolare quando ragioniamo su API a basso livello), ma se poi qualcuno applica il suo ragionamento a occhi chiusi, senza fare delle considerazioni sul programma specifico che sta realizzando, i risultati sono senz’altro pessimi.

Ingo Rammer scrive su MSDN

Ingo Rammer, famoso per essere il guru di Remoting, ha scritto un articolo per MSDN. La notizia è che l’articolo non è su Remoting ma su WSE 2.0. Dunque, dobbiamo pensare che Remoting sia già sul viale del tramonto? Io e Paolo siamo d’accordo sul fatto che il futuro sia dei Web Service, con le dovute eccezioni (e in quei casi, comunque, non è sempre detto che Remoting sia una soluzione migliore).
Attenzione, non ho detto che Remoting non serve…

Jan Gray a PDC

Sempre su segnalazione di Brad Abrams, pare che una sessione da non perdere a PDC sia quella di Jan Gray (che ancora non compare sul sito). Purtroppo so già che a PDC sarò depresso per tutte le sessioni che dovrò perdere (ce ne saranno sempre almeno 3 o 4 “da vedere” alla stessa ora), comunque segnamo anche questa nota…

Longhorn, WinFS e System.Search

Una sessione di PDC che non avevo ancora notato (magari è stata inserita da poco) è la CLI327 (System.Search: Natural Language Access to Data). In breve, sembra di capire che in Longhorn ci sia un API managed per l’accesso a un motore che interpreta (ed esegue?) query in linguaggio naturale. Purtroppo la descrizione non dice molto di più e in particolare sarebbe interessante capire se si tratta di un’evoluzione di English Query (che supporta solo l’inglese) o se il passo in avanti è più deciso e sono supportate lingue diverse.
Mi pare ovvio che WinFS (il nuovo storage di Longhorn) sia strettamente correlato a queste classi.
L’attesa per PDC comincia ad aumentare, ho sempre più domande a cui trovare risposta.

GetHashCode e prestazioni

Brad Abrams fa alcune considerazioni nel suo blog rispetto all’uso di GetHashCode. A parte le avvertenze (c’è qualcuno che confonde l’uso di GetHashCode con un ID univoco dell’oggetto… non è così, basta leggere la documentazione), la parte interessante è la considerazione relativa alle prestazioni.
Il valore restituito da questa GetHashCode è il puntatore al SyncBlock dell’oggetto. Questo oggetto (unmanaged) è creato solo se necessario: normalmente ciò avviene per la prima chiamata di Monitor.Enter (lock in C# e SyncLock in VB.NET), ma la stessa necessità è presente chiamando GetHashCode.
Nella versione 1.0 e 1.1 di .NET questa è l’implementazione di GetHashCode, che cambierà nelle versioni successive. Nel frattempo, se qualcuno ha bisogno di migliorare le prestazioni di un programma che usa tale metodo, può ridefinire GetHashCode per le sue classi, magari generando un numero random nel costruttore che viene poi memorizzato in un campo privato (più o meno quello che dovrebbe fare la prossima versione di .NET).