Astăzi vă voi spune despre minunatele indieni de la Microsoft. care la început fac și apoi gândesc.
Mai exact, va fi vorba despre Tusky. Nu voi scrie despre ele, căci aceasta nu este tema postului de astăzi. Pe scurt, acestea sunt acele fire pe steroizi cu caracteristici gustoase și convenabile.
Una dintre caracteristici este expedierea executabililor. Aproximativ astfel:
Ie facem ceva într-un fir separat, în acest moment ne ocupăm de lucrurile noastre și apoi ne asigurăm că sarcina sa încheiat și a prins excepția care ne-a fost împachetată în AggregateException (prezentul este ascuns în el).
Ie se dovedește o caracteristică destul de interesantă, puteți savura sincer excepții de la alte fire în momentul în care știm cum să ne descurcăm. Și acest lucru poate fi folosit în mod activ (de exemplu, ascunderea tuturor lucrărilor paralele în cadrul metodei, dar aruncarea excepțiilor).
Dar există o nuanță mică. La urma urmei, este aruncat afară, când ceva așteaptă taska (rezultatul sau pur și simplu finalizarea). În terminologia standard, acest lucru se numește observabil. Ie Sarcina trebuie să fie observabilă. Și dacă am pornit și am uitat (sau am marcat)?
Se pare că implementarea undeva este pierdută? Indiferent cum este! Specialiști valoroși de la Microsoft s-au gândit și au venit cu o excepție în distrugător. Evaluați eleganța acestei soluții: aceasta încalcă toate standardele normale de codificare, duce la o scădere a cererii și dă erori la momentul respectiv și în locul în care este imposibil să le prindem deloc. Super!
Probabil, ei au decis că, din moment ce excepția din firul obișnuit face ca aplicația să se prăbușească, atunci este necesară. Doar am uitat de această mică diferență, cu excepții: dacă vrem să facem un fir normal mai sigur, trebuie doar să scriem o încercare / captura și toată lumea va fi fericită (încă nimeni nu va gestiona eroarea pentru noi). Iar cu cazul, aruncarea unei excepții din interior ar putea fi uneori utilă. Dar se dovedește că aceste sarcini trebuie privite ca și pentru copiii mici, deși este posibil să nu aruncăm nimic despre rezultatul unei anumite operațiuni în acest loc.
Soluțiile la această problemă, în principiu, puteți veni cu câteva (ambalaje diferite, monitorizați utilizarea sarcinilor), una dintre cele mai frumoase este:
Ie noi creăm o metodă de extensie care atribuie o continuare activității noastre, în care luăm valoarea proprietății Excepție (aceasta trebuie făcută! doar pentru ca sarcina să devină din nou observabilă), și în acest fel calmăm sistemul.
Sarcina este rezolvată și sper că vă va provoca o mată mai mică decât am avut în ziua mea, când am căzut pentru o astfel de problemă. Și am căzut din cauza asta pentru încă un motiv.
La început nu am scris în zadar, că Microsoft a făcut-o mai întâi și apoi au început să se gândească. Și după ce au gândit, au dat seama că comportamentul este prea dureros pentru a fi idiotic și nimeni nu trebuie să omoare întreaga aplicație. Și în 4.5 a schimbat logica, deci pentru 4.5 deja postul meu este irelevant.
Dar fără nuanțe, Microsoft nu face, pentru că 4,5 înlocuiește de fapt 4.0. Surpriză! Ie setarea 4.5, toate aplicațiile scrise sub 4.0 încep să funcționeze de fapt pe 4.5, și puțin diferit. De exemplu, în acest caz, eroarea nu va apărea (există și alte diferențe în comportament, dar acest lucru este prea pronunțat). Puteți restaura vechiul comportament la un fișier de configurare. dar care deranjează să citească toate setările nebune și inutile?
Uneori, vrei doar să-ți ucizi capul de perete de la astfel de transformări de geniu ale complotului.
Trimiteți-le prietenilor: