gennaio 2007 Blog Posts
Sinceramente non ho visto molte applicazioni (non demo) basate su WPF. Al CES e' stato annunciato Yahoo Messenger per Vista interamente bastato su WPF.
Quante volte abbiamo implementato il metodo di invio dell'evento in questo modo
protected void OnMyEvent(MyEventArg e) { if(MyEvent != null) MyEvent(this, e);}
Sembra giusto vero? Ma che cosa succede se due thread fanno la stessa chiamata ed in un certo momento (vogliamo mettere alla prova la legge di Murphy?...sicuramente succede durante la demo al cliente!) uno dei due thread de-sottoscrive all'evento (MyEvent diventa null) proprio quando l'altro thread ha gia' verificato che MyEvent non sia null? Bang, NullReferenceException!
Ecco la soluzione al problema:
protected void OnMyEvent(MyEventArg e) { MyEventHandler temp = MyEvent; if(temp != null) temp(this, e);}
semplice no?
Quando si sviluppano applicazioni windows (WinForms) e scatta un'eccezione che cosa facciamo? Come consuetidine logghiamo l'informazione ed informiamo l'utente che qualcosa e' andato storto. Se l'eccezione sollevata e' molto seria apparira' il classico messaggio “..contattare l'amministratore...”.
Non voglio subentrare nella dialettica di che cosa sia giusto scrivere oppure no, non ne usciremmo vivi. Mi interessa invece ricordare un post molto interessante di Szymon nel quale illustra un'API .NET per visualizzare una dialog box per le eccezzioni. Prima di utilizzarla, e' bene pensare al nostro target: la nostra applicazione e' per geek o per utenti basic?
Quando si migra il proprio codice da NUnit a Team Test (Unit testing) e' necessario prestare molta attenzione non solo agli attributi ed al nemaspace (in questo caso non avrebbe successo la compilazione) ma anche al differente comportamento degli Assert.
Per differente comportamento intendo due tipologie di risultato classificabili come effetti indesiderati e come malfunzionamenti veri e propri.
Tanto per citare un esempio di effetto indesiderato possiamo prendere il caso dell'Assert.AreEqual su due stringhe. Nel caso di NUnit se le stringhe sono differenti verra' evidenziato l'indice del primo elemento differente. Con Team Test sapremo solo che sono differenti, ma non dove. Per...
Immaginiamo di avere una classe definita come segue in un nostro assembly:
internal class Executer{ private void Print(string name) { Console.WriteLine("Hello " + name); }}
Siamo davvero sicuri che nessuno al difuori dei metodi della nostra classe possano chiamare Print? La risposta è ovviamente no. Basta usare reflection e diventa possibile chiamare Print anche da un'altro assembly:
Type type = Type.GetType("Demo.Validator.Executer, Demo.Validator", false);MethodInfo method = type.GetMethod("Print", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance);method.Invoke(Activator.CreateInstance(type, true), new object[] { "World" });
Questo esempio basta ed avanza per convincerci che anche i metodi privato richiedono un controllo accurato dei parameri di input ;-)