İstisnai güvenlik için "kapsamlı davranış" elde etmenin bir yolu olarak IDisposable kullanmak ve "kullanmak" kötüye kullanım mıdır?

C ++ 'da sıklıkla kullandığım bir şey, bir sınıfın Abaşka bir sınıf için bir durum girişi ve çıkış koşulunu kurucu ve yıkıcı Baracılığıyla işlemesine izin Avermekti, bu kapsamdaki bir şey bir istisna atarsa, B'nin bilinen bir duruma sahip olacağından emin olmak için kapsamdan çıkıldı. Kısaltmaya göre bu saf RAII değil, ancak yine de yerleşik bir kalıp.

C # 'da sık sık yapmak istiyorum

class FrobbleManager
{
    ...

    private void FiddleTheFrobble()
    {
        this.Frobble.Unlock();
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
        this.Frobble.Lock();
    }
}

Hangisinin böyle yapılması gerekiyor

private void FiddleTheFrobble()
{
    this.Frobble.Unlock();

    try
    {            
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
    }
    finally
    {
        this.Frobble.Lock();
    }
}

Döndüğünde Frobbledevleti garanti etmek istersem FiddleTheFrobble. Kod ile daha güzel olurdu

private void FiddleTheFrobble()
{
    using (var janitor = new FrobbleJanitor(this.Frobble))
    {            
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
    }
}

nerede FrobbleJanitorgörünüyor kabaca gibi

class FrobbleJanitor : IDisposable
{
    private Frobble frobble;

    public FrobbleJanitor(Frobble frobble)
    {
        this.frobble = frobble;
        this.frobble.Unlock();
    }

    public void Dispose()
    {
        this.frobble.Lock();
    }
}

Ben de böyle yapmak istiyorum. Ne yana Şimdi gerçeklik yetişene istediğiniz kullanımına ihtiyaç olduğu FrobbleJanitorkullanılır ile using . Bunu bir kod inceleme sorunu olarak düşünebilirim, ancak bir şey beni rahatsız ediyor.

Soru: Would yukarıda küfürlü kullanımı gibi düşünülebilir usingve IDisposable?

İlle de öyle düşünmüyorum. Teknik olarak IDisposable , yönetilmeyen kaynaklara sahip şeyler için kullanılmak üzere tasarlanmıştır, ancak daha sonra kullanma yönergesi try .. finally { dispose },.

Bir pürist, "evet - taciz edicidir" ve saf anlamıyla öyledir; ama çoğumuz pürist bir bakış açısıyla değil, yarı sanatsal bir bakış açısıyla kodluyoruz. "Kullanarak" yapıyı bu şekilde kullanmak, bence gerçekten oldukça sanatsal.

Muhtemelen IDisposable'ın üstüne başka bir arayüz yapıştırarak onu biraz daha uzağa itmelisiniz ve diğer geliştiricilere bu arayüzün neden IDisposable olduğunu açıklamalısınız.

Bunu yapmanın pek çok başka alternatifi var ama nihayetinde bu kadar düzgün olacağını düşünemiyorum, o yüzden devam et!

Bunu, kullanım ifadesinin kötüye kullanılması olarak görüyorum. Bu pozisyonda azınlıkta olduğumun farkındayım.

Bunu üç nedenden dolayı kötüye kullanma olarak görüyorum.

Birincisi, "kullanma" nın bir kaynağı kullanmak ve onunla işiniz bittiğinde onu atmak için kullanılmasını bekliyorum . Program durumunu değiştirmek bir kaynak kullanmamaktır ve onu geri değiştirmek hiçbir şeyi elden çıkarmaz. Bu nedenle, durumu değiştirmek ve geri yüklemek için "kullanmak" kötüye kullanımdır; kod sıradan okuyucular için yanıltıcıdır.

İkincisi, "kullanma" nın gereklilikten değil, nezaketten kullanılmasını bekliyorum . İşiniz bittiğinde bir dosyayı imha etmek için "kullanma" seçeneğini kullanmanızın nedeni, bunun gerekli olması değil, kibar olmasıdır - başka biri o dosyayı kullanmak için bekliyor olabilir, bu yüzden "bitti" şimdi "ahlaki olarak yapılacak doğru şeydir. Kullanılmış kaynağın daha uzun süre tutulması ve daha sonra atılması için bir "kullanımı" yeniden düzenleyebilmeyi ve bunu yapmanın tek etkisinin diğer süreçleri biraz rahatsız etmek olmasını bekliyorum . Program durumu üzerinde anlamsal etkisi olan "kullanan" bir blok zorunluluk değil, kolaylık ve nezaket için varmış gibi görünen bir yapıda program durumunun önemli, gerekli bir mutasyonunu gizlediği için kötüye kullanılır.

Üçüncüsü, programınızın eylemleri durumuna göre belirlenir; Devletin dikkatli manipülasyonuna duyulan ihtiyaç tam da bu konuşmayı ilk etapta yapmamızın nedenidir. Orijinal programınızı nasıl analiz edebileceğimizi düşünelim.

Bunu ofisimdeki bir kod incelemesine götürseydiniz, soracağım ilk soru "bir istisna atılırsa frobble'ı kilitlemek gerçekten doğru mu?" Programınızdan, bu şeyin ne olursa olsun gevezeliği agresif bir şekilde yeniden kilitlediği apaçık ortadadır. Bu doğru mu? Bir istisna atıldı. Program bilinmeyen bir durumda. Foo, Fiddle veya Bar'ın atıp atmadığını, neden fırlattıklarını veya temizlenmemiş başka bir duruma hangi mutasyonları gerçekleştirdiklerini bilmiyoruz. Beni o korkunç durumda yeniden kilitlemenin her zaman yapılacak doğru şey olduğuna ikna edebilir misin ?

Belki öyledir, belki de değildir. Demek istediğim, kod ilk yazıldığı haliyle , kod gözden geçiren kişinin soruyu sorması gerektiğini biliyor . "Kullanarak" kullanan kodla, soruyu sormam gerektiğini bilmiyorum; Bunun, yapılmazsa o zaman blok ayırır kaynak, biraz kullanır bunu ve bunun kibarca hizmetinde "kullanılarak" farz kapanış ayracı "kullanılarak" blok içinde mutasyon keyfi pek istisnai cirumstance içinde benim program devlet program durumu tutarlılık koşulları ihlal edildi.

Anlamsal bir etkiye sahip olmak için "kullanma" bloğunun kullanılması, bu program parçasını yapar:

}

son derece anlamlı. Bu tek yakın ayraca baktığımda, "bu küme ayracın, programımın küresel durumu üzerinde geniş kapsamlı etkileri olan yan etkileri olduğunu" hemen düşünmüyorum. Ama bu şekilde "kullanmayı" kötüye kullandığınızda, aniden kötüye gidiyor.

Orijinal kodunuzu görürsem soracağım ikinci şey, "Kilit Açma işleminden sonra ancak deneme girilmeden önce bir istisna atılırsa ne olur?" Optimize edilmemiş bir derleme çalıştırıyorsanız, derleyici denemeden önce işlemsiz bir talimat eklemiş olabilir ve işlemsiz durumda bir iş parçacığı iptal istisnasının gerçekleşmesi mümkündür. Bu nadirdir, ancak gerçek hayatta özellikle web sunucularında olur. Bu durumda, kilit açma gerçekleşir ancak kilit asla olmaz, çünkü istisna denemeden önce fırlatılır. Bu kodun bu soruna karşı savunmasız olması tamamen mümkündür ve aslında yazılmalıdır

bool needsLock = false;
try
{
    // must be carefully written so that needsLock is set
    // if and only if the unlock happened:

    this.Frobble.AtomicUnlock(ref needsLock);
    blah blah blah
}
finally
{
    if (needsLock) this.Frobble.Lock();
}

Yine olabilir, belki olmaz, ama soruyu sormayı biliyorum . "Kullanan" sürümle, aynı soruna karşı hassastır: Frobble kilitlendikten sonra, ancak kullanımla ilişkili deneme korumalı bölge girilmeden önce bir iş parçacığı iptal istisnası atılabilir. Ancak "kullanma" sürümüyle, bunun "ne olmuş yani?" Olduğunu varsayıyorum. durum. Bunun olması talihsiz bir durumdur, ancak "kullanma" nın hayati önem taşıyan program durumunu değiştirmek için değil, yalnızca kibar olmak için olduğunu varsayıyorum. Sanırım, bazı korkunç iş parçacığı iptali istisnası tam olarak yanlış zamanda meydana gelirse, o zaman, o zaman, çöp toplayıcının sonunda sonlandırıcıyı çalıştırarak bu kaynağı temizleyeceğini varsayıyorum.

Temiz, kapsamlı bir kod istiyorsanız, ayrıca lambdas, á la

myFribble.SafeExecute(() =>
    {
        myFribble.DangerDanger();
        myFribble.LiveOnTheEdge();
    });

burada .SafeExecute(Action fribbleAction)yöntem, sarar try- catch- finallyblok.

C # dil tasarım ekibinde yer alan Eric Gunnerson, hemen hemen aynı soruya şu cevabı verdi :

Doug soruyor:

re: Zaman aşımına sahip bir kilit ifadesi ...

Bu numarayı daha önce çeşitli yöntemlerde ortak kalıplarla uğraşmak için yaptım . Genellikle edinimi kilitler , ancak başkaları da vardır . Sorun şu ki, nesne " kapsamın sonunda geri arama " kadar gerçekten tek kullanımlık olmadığından, her zaman bir hack gibi hissettiriyor .

Doug

Using ifadesine karar verdiğimizde, tam olarak bu senaryo için kullanılabilmesi için nesneleri atmaya daha özel bir şeyden ziyade "kullanarak" olarak adlandırmaya karar verdik.

Kaygan bir yokuş. IDisposable'ın bir sonlandırıcı tarafından desteklenen bir sözleşmesi var. Senin durumunda bir sonuçlandırıcı işe yaramaz. Müşteriyi using ifadesini kullanmaya zorlayamazsınız, yalnızca onu kullanmaya teşvik edin. Bunu aşağıdaki gibi bir yöntemle zorlayabilirsiniz:

void UseMeUnlocked(Action callback) {
  Unlock();
  try {
    callback();
  }
  finally {
    Lock();
  }
}

Ama bu, lamdalar olmadan biraz tuhaf olma eğilimindedir. Bununla birlikte, senin yaptığın gibi IDisposable kullandım.

Ancak yazınızda bunu tehlikeli bir şekilde anti-desene yaklaştıran bir ayrıntı var. Bu yöntemlerin bir istisna oluşturabileceğinden bahsettiniz. Bu, arayan kişinin görmezden gelebileceği bir şey değildir. Bununla ilgili üç şey yapabilir:

• Hiçbir şey yapmayın, istisna kurtarılamaz. Normal durum. Unlock'u aramak önemli değil.
• İstisnayı yakalayın ve işleyin
• Durumu kodunda geri yükleyin ve istisnanın çağrı zincirini geçmesine izin verin.

Son ikisi, arayanın açıkça bir try bloğu yazmasını gerektirir. Şimdi using ifadesi önümüze çıkıyor. Bir müşteriyi komaya sokarak onu sınıfınızın devletle ilgilendiğine ve ek bir işin yapılmasına gerek olmadığına inandırabilir. Bu neredeyse hiçbir zaman doğru değildir.

Gerçek bir dünya örneği, ASP.net MVC'nin BeginForm'udur. Temel olarak şunları yazabilirsiniz:

Html.BeginForm(...);
Html.TextBox(...);
Html.EndForm();

veya

using(Html.BeginForm(...)){
    Html.TextBox(...);
}

Html.EndForm Dispose çağırır ve Dispose yalnızca </form>etiketi çıkarır . Bununla ilgili iyi olan şey, {} parantezlerinin görünür bir "kapsam" oluşturmasıdır, bu da formun içinde neyin olup olmadığını görmeyi kolaylaştırır.

Aşırı kullanmazdım, ama özünde IDisposable, "İşiniz bittiğinde bu işlevi çağırmanız GEREKİR" demenin bir yolu. MvcForm bunu formun kapalı olduğundan emin olmak için kullanır, Akış bunu akışın kapalı olduğundan emin olmak için kullanır, nesnenin kilidinin açıldığından emin olmak için bunu kullanabilirsiniz.

Şahsen bunu yalnızca aşağıdaki iki kural doğruysa kullanırdım, ancak bunlar benim tarafımdan keyfi olarak belirlenir:

• Dispose, her zaman çalışması gereken bir işlev olmalıdır, bu nedenle Null-Checks dışında herhangi bir koşul olmamalıdır
• Dispose () işleminden sonra, nesne yeniden kullanılabilir olmamalıdır. Yeniden kullanılabilir bir nesne isteseydim, elden çıkarmak yerine ona açma / kapama yöntemleri vermeyi tercih ederim. Bu yüzden, atılmış bir nesneyi kullanmaya çalışırken InvalidOperationException oluşturuyorum.

Sonunda, her şey beklentilerle ilgili. Bir nesne IDisposable uygularsa, biraz temizleme yapması gerektiğini varsayıyorum, bu yüzden onu çağırıyorum. Sanırım genellikle bir "Kapat" işlevine sahip olmaktan daha iyidir.

Bununla birlikte, bu satırı sevmiyorum:

this.Frobble.Fiddle();

Frobble Janitor artık Frobble'ın "sahibi" olduğundan, bunun yerine Janitor'daki Frobble'a Fiddle demek daha iyi olmaz mıydı acaba?

Kod tabanımızda bu kalıbı bolca kullanıyoruz ve daha önce her yerde görmüştüm - eminim burada da tartışılmış olmalı. Genel olarak bunu yapmanın neyin yanlış olduğunu görmüyorum, yararlı bir model sağlıyor ve gerçek bir zarara yol açmıyor.

Şuna inanıyorum: Buradaki çoğuna bunun kırılgan ama yararlı olduğu konusunda hemfikirim. Sizi, yapmak istediğiniz gibi bir şey yapan System.Transaction.TransactionScope sınıfına yönlendirmek istiyorum.

Genelde sözdizimini seviyorum, gerçek etten çok fazla dağınıklığı ortadan kaldırıyor. Lütfen yardımcı sınıfa iyi bir isim vermeyi düşünün - belki ... Yukarıdaki örnekte olduğu gibi Kapsam. İsim, bir kod parçasını kapsadığını belirtmelidir. * Kapsam, * Blok veya benzeri bir şey yapmalıdır.

Not: Bakış açım muhtemelen C ++ geçmişime göre önyargılıdır, bu nedenle cevabımın değeri bu olası önyargıya karşı değerlendirilmelidir ...

C # Dil Spesifikasyonu Ne Diyor?

C # Dil Belirtiminden Alıntı :

8.13 using ifadesi

[...]

Bir kaynak bir sınıf veya yapı olup bertaraf adlı tek parametresiz yöntemi içerir uygular System.IDisposable, bu. Bir kaynağı kullanan kod, kaynağa artık ihtiyaç olmadığını belirtmek için Dispose çağırabilir. Dispose çağrılmazsa, çöp toplamanın bir sonucu olarak sonunda otomatik imha gerçekleşir.

Bir kaynak kullanıyor Kod elbette kod ile başlıyor usinganahtar kelime ve kapsamı ekli kadar devamusing .

Sanırım bu sorun değil çünkü Kilit bir kaynak.

Belki de anahtar kelime usingkötü seçilmiştir. Belki de çağrılmalıydıscoped .

O zaman neredeyse her şeyi bir kaynak olarak düşünebiliriz. Bir dosya tanıtıcısı. Bir ağ bağlantısı ... Bir ileti dizisi mi?

Bir ileti dizisi ???

usingAnahtar kelimeyi kullanmak (veya kötüye kullanmak) ?

O olurdu parlak kullanın (ab) usingemin parçacığının iş kapsamını çıkmadan önce sona yapmaya anahtar kelimeyi?

Herb Sutter , bir iş parçacığının çalışmasının bitmesini beklemek için IDispose modelinin ilginç bir kullanımını sunduğu için parlak olduğunu düşünüyor gibi görünüyor :

http://www.drdobbs.com/go-parallel/article/showArticle.jhtml?articleID=225700095

İşte makaleden kopyalanıp yapıştırılan kod:

// C# example
using( Active a = new Active() ) {    // creates private thread
       …
       a.SomeWork();                  // enqueues work
       …
       a.MoreWork();                   // enqueues work
       …
} // waits for work to complete and joins with private thread

Etkin nesnenin C # kodu sağlanmadığında, C #, yıkıcıda C ++ sürümü bulunan kod için IDispose modelini kullanır. Ve C ++ sürümüne bakarak, makalenin bu diğer özünde gösterildiği gibi, çıkmadan önce iç iş parçacığının bitmesini bekleyen bir yıkıcı görüyoruz:

~Active() {
    // etc.
    thd->join();
 }

Yani, Herb söz konusu olduğunda, parlak .

Sorunuzun cevabının hayır olduğuna inanıyorum, bu kötüye kullanım değil IDisposable.

IDisposableArayüzü anlamamın yolu , bir nesne atıldıktan sonra onunla çalışmamanız gerektiğidir (bunun dışında, Disposeyöntemini istediğiniz sıklıkta çağırmanıza izin verilir ).

İfadeye her geldiğinizde açıkça yeni bir şey oluşturduğunuz için, aynı nesneyi asla iki kez kullanmazsınız. Ve amacı başka bir nesneyi yönetmek olduğu içinFrobbleJanitorusingFrobbeJanitorDispose bu ("yönetilen") kaynağı serbest bırakma görevine uygun görünüyor.

(Btw., DisposeHemen hemen her zaman doğru uygulamayı gösteren standart örnek kod , yalnızca dosya sistemi tanıtıcıları gibi yönetilmeyen kaynakların değil, yönetilen kaynakların da serbest bırakılması gerektiğini önerir.)

Kişisel olarak endişelendiğim tek şey, ne olduğu ve operasyonların doğrudan görülebildiği using (var janitor = new FrobbleJanitor())daha açık bir try..finallybloktan daha az net olmasıdır . Ancak hangi yaklaşımın benimseneceği muhtemelen kişisel tercihlere bağlıdır.LockUnlock

Kötüye kullanım değil. Onları yaratıldıkları için kullanıyorsunuz. Ancak ihtiyaçlarınıza göre birbirini düşünmeniz gerekebilir. Örneğin, "artistry" yi seçiyorsanız, "kullanma" yı kullanabilirsiniz, ancak kod parçanız birçok kez çalıştırılırsa, performans nedeniyle "deneyin" .. "en sonunda" yapılarını kullanabilirsiniz. Çünkü 'kullanmak' genellikle bir nesnenin yaratılmasını içerir.

Bence doğru yaptın. Dispose () aşırı yükleme, aynı sınıfın daha sonra temizlemek zorunda olduğu bir problemdi ve bu temizlemenin ömrü, kilit tutmayı beklediğiniz zamandan farklı olacak şekilde değişti. Ancak, yalnızca Frobble'ı kilitlemek ve kilidini açmaktan sorumlu olan ayrı bir sınıf (FrobbleJanitor) oluşturduğunuz için, işler yeterince ayrıştırılır, bu sorunu çözmezsiniz.

FrobbleJanitor'ı muhtemelen FrobbleLockSession gibi bir şeye yeniden adlandırırdım.