Asynkronisen ohjelmoinnin avulla voit suorittaa resursseja kuluttavia I / O-operaatioita ilman, että sinun on estettävä sovelluksen pää- tai suoritussäike. Vaikka se on hyödyllinen ja näennäisesti helppo toteuttaa, siihen liittyy paljon monimutkaisuutta ja riskejä. Asynkronoinnin ohjelmointiin mahdollisesti liittyvät riskit, erityisesti asynkronisen ohjelmoinnin väärällä käytöllä noudattamatta suositeltuja käytäntöjä, ovat umpikuja, prosessin kaatuminen ja jopa hidas suorituskyky. Sinun tulisi myös osata kirjoittaa, asynkronikoodien virheenkorjaus.
Vältä tyhjän palautustyypin asettamista asynkronointimenetelmissä
Menetelmä C #: ssä tehdään asynkroniseksi menetelmäksi käyttämällä asynkronista avainsanaa menetelmän allekirjoituksessa. Asynkronointimenetelmässä voi olla yksi tai useampi odottava avainsana. Odota-avainsanaa käytetään merkitsemään keskeytyskohtaa. C #: n asynkronointimenetelmällä voi olla jokin näistä palautustyypeistä: Tehtävä, Tehtävä ja void. "Odota" -avainsanaa käytetään asynkronimenetelmässä ilmoittaakseen kääntäjälle, että menetelmällä voi olla keskeytys- ja jatkamispiste.
Huomaa, että kun käytetään TPL: ää, TPL: ssä olevan tyhjän palautuksen ekvivalentti on asynkroninen tehtävä. Sinun tulisi olla tietoinen siitä, että async void on ja sitä tulisi käyttää vain asynkronointitapahtumiin. Jos käytät sitä muualla, saatat törmätä virheisiin. Toisin sanoen asynkronimenetelmää, jonka palautustyyppi on tyhjä, ei suositella. koska tyhjäksi palautuvilla asynkronointimenetelmillä on erilainen semantiikka, kun työskentelet sovelluksen poikkeusten kanssa.
Kun poikkeus tapahtuu asynkronimenetelmässä, jonka palautustyyppi on Tehtävä tai Tehtävä, poikkeusobjekti tallennetaan Tehtävä-objektiin. Päinvastoin, jos sinulla on asynkronointimenetelmä, jonka palautustyyppi on void, Task-objektia ei ole liitetty. Tällaisia poikkeuksia tuodaan esiin synkronointikontekstissa, joka oli aktiivinen asynkronisen menetelmän kutsumisajankohtana. Toisin sanoen, et voi käsitellä asynkronisen void -menetelmän yhteydessä nostettuja poikkeuksia käyttämällä asynkronisen menetelmän sisällä kirjoitettuja poikkeuskäsittelijöitä. Asynkkomenetelmiä, joilla on palautustyyppi, mitätöinti on myös vaikea testata tämän eron vuoksi virheiden käsittelyn semantiikassa. Tietosi vuoksi SynchronizationContext-luokka System.Threading-nimiavaruudessa edustaa synkronointikontekstia .Netissä ja auttaa sinua jonottamaan tehtävän toiseen kontekstiin.
Seuraava koodiluettelo kuvaa tätä. Sinulla on kaksi tapaa, nimittäin Test ja TestAsync, ja jälkimmäinen heittää poikkeuksen.
julkinen luokka AsyncDemo
{
julkinen mitätöinti ()
{
yrittää
{
TestAsync ();
}
saalis (poikkeus ex)
{
Console.WriteLine (ex.Message);
}
}
yksityinen asynkronointi void TestAsync ()
{
heittää uusi poikkeus ("Tämä on virheilmoitus");
}
}
Näin voit luoda AsyncDemo-luokan ilmentymän ja käynnistää testimenetelmän.
staattinen void Main (merkkijono [] args)
{
AsyncDemo obj = uusi AsyncDemo ();
obj.Testi ();
Konsoli.Lue ();
}
Testimenetelmä kutsuu TestAsync-menetelmää ja kutsu kääritään try-catch-lohkoon tarkoituksena käsitellä TestAsync-menetelmän sisään heitettyä poikkeusta. TestAsync-menetelmän sisään heitettyä poikkeusta ei kuitenkaan koskaan saada kiinni, ts. Sitä ei käsitellä soittajan menetelmän Testissä.
Vältä asynkronisen ja synkronisen koodin sekoittamista
Sinulla ei pitäisi koskaan olla sekoitusta synkronista ja asynkronista koodia. On huono ohjelmointikäytäntö estää asynkronointikoodi soittamalla Task.Wait tai Task.Result. Suosittelen käyttämään asynkronikoodia päästä päähän - se on turvallisin tapa välttää virheitä piiloutumasta.
Voit välttää umpikujat käyttämällä.ConfigureAwait (jatkaOnCapturedContext: väärä) aina kun soitat odottamaan. Jos et käytä tätä, asynkronointitapa estyy siinä kohdassa, jossa odottaa on kutsuttu. Tässä tapauksessa ilmoitat vain tarjoilijalle, ettei se ota kiinni nykyisestä tilanteesta. Sanoisin, että .ConfigureAwait (false) on hyvä käytäntö, ellei sinulla ole erityistä syytä olla käyttämättä sitä.
Haluaisin keskustella lisää asynkronisesta ohjelmoinnista tulevissa blogiviesteissäni täällä. Lisätietoja asynkronisen ohjelmoinnin parhaista käytännöistä on Stephen Clearyn suuressa artikkelissa MSDN: ssä.
