Sintaks apa yang paling halus dan paling menarik yang Anda temukan untuk menegaskan kebenaran parameter di c#?

Ini mungkin sedikit membantu:

Desain berdasarkan kontrak/C# 4.0/avoiding ArgumentNullException

Anda harus memeriksa Kontrak Kode; mereka melakukan persis seperti yang Anda minta. Contoh:

[Pure]
public static double GetDistance(Point p1, Point p2)
{
    CodeContract.RequiresAlways(p1 != null);
    CodeContract.RequiresAlways(p2 != null); 
    // ...
}

Wow, saya menemukan sesuatu yang sangat menarik di sini. Chris di atas memberikan tautan ke pertanyaan Stack Overflow lainnya. Salah satu jawaban di sana menunjuk ke postingan blog yang menjelaskan cara mendapatkan kode seperti ini:

public static void Copy<T>(T[] dst, long dstOffset, T[] src, long srcOffset, long length)
{
    Validate.Begin()
            .IsNotNull(dst, “dst”)
            .IsNotNull(src, “src”)
            .Check()
            .IsPositive(length)
            .IsIndexInRange(dst, dstOffset, “dstOffset”)
            .IsIndexInRange(dst, dstOffset + length, “dstOffset + length”)
            .IsIndexInRange(src, srcOffset, “srcOffset”)
            .IsIndexInRange(src, srcOffset + length, “srcOffset + length”)
            .Check();

    for (int di = dstOffset; di < dstOffset + length; ++di)
        dst[di] = src[di - dstOffset + srcOffset];
}

Saya belum yakin ini adalah jawaban yang terbaik, namun tentu saja ini menarik. Berikut postingan blognya , dari Rick Brewster.

Saya mengatasi masalah ini beberapa minggu yang lalu, setelah berpikir bahwa aneh bagaimana perpustakaan pengujian tampaknya memerlukan jutaan versi Assert yang berbeda untuk membuat pesan mereka deskriptif.

Inilah solusi saya.

Ringkasan singkat - diberikan sedikit kode ini:

int x = 3;
string t = "hi";
Assert(() => 5*x + (2 / t.Length) < 99);

Fungsi Assert saya dapat mencetak ringkasan berikut tentang apa yang diteruskan ke dalamnya:

(((5 * x) + (2 / t.Length)) < 99) == True where
{
  ((5 * x) + (2 / t.Length)) == 16 where
  {
    (5 * x) == 15 where
    {
      x == 3
    }
    (2 / t.Length) == 1 where
    {
      t.Length == 2 where
      {
        t == "hi"
      }
    }
  }
}

Jadi semua nama dan nilai pengidentifikasi, serta struktur ekspresi, dapat disertakan dalam pesan pengecualian, tanpa Anda harus menyatakannya kembali dalam string yang dikutip.

Baiklah teman-teman, ini saya lagi, dan saya menemukan hal lain yang mencengangkan dan menyenangkan. Ini adalah postingan blog lain yang dirujuk dari pertanyaan SO lainnya yang disebutkan Chris di atas.

Pendekatan orang ini memungkinkan Anda menulis ini:

public class WebServer
    {
        public void BootstrapServer( int port, string rootDirectory, string serverName )
        {
            Guard.IsNotNull( () => rootDirectory );
            Guard.IsNotNull( () => serverName );

            // Bootstrap the server
        }
    }

Perhatikan bahwa tidak ada string yang berisi "rootDirectory" dan tidak ada string yang berisi "serverName"!! Namun pesan kesalahannya dapat mengatakan sesuatu seperti "Parameter rootDirectory tidak boleh nol."

Inilah yang saya inginkan dan lebih dari yang saya harapkan. Berikut tautan ke postingan blog pria tersebut.

Dan implementasinya cukup sederhana, sebagai berikut:

public static class Guard
    {
        public static void IsNotNull<T>(Expression<Func<T>> expr)
        {
            // expression value != default of T
            if (!expr.Compile()().Equals(default(T)))
                return;

            var param = (MemberExpression) expr.Body;
            throw new ArgumentNullException(param.Member.Name);
        }
    }

Perhatikan bahwa ini menggunakan "refleksi statis", jadi dalam lingkaran ketat atau semacamnya, Anda mungkin ingin menggunakan pendekatan Rick Brewster di atas.

Segera setelah saya memposting ini, saya akan memilih Chris, dan jawaban terhadap pertanyaan SO lainnya. Ini barang bagus!!!

Menggunakan perpustakaan saya Tritunggal Pembantu:

public void SomeMethod(string firstName, string lastName, int age)
{
    firstName.AssertNotNull("firstName");
    lastName.AssertNotNull("lastName");

    ...
}

Juga mendukung penegasan bahwa parameter enumerasi sudah benar, koleksi dan isinya bukan-null, parameter string tidak kosong, dan sebagainya. Lihat dokumentasi pengguna di sini untuk contoh detail .

Inilah jawaban saya untuk masalah ini. Saya menyebutnya "Guard Claws". Ia menggunakan parser IL dari Lokad Shared Libs tetapi memiliki pendekatan yang lebih mudah untuk menyatakan klausa penjaga sebenarnya:

string test = null;
Claws.NotNull(() => test);

Anda dapat melihat lebih banyak contoh penggunaannya di spesifikasi .

Karena menggunakan lambda asli sebagai masukan dan menggunakan IL Parser hanya untuk menghasilkan pengecualian jika terjadi pelanggaran, kinerjanya akan lebih baik di "jalur bahagia" daripada desain berbasis Ekspresi di tempat lain dalam jawaban ini.

Tautan tidak berfungsi, berikut URL-nya: http://github.com/littlebits/guard_claws/

Perpustakaan Bersama Lokad juga memiliki implementasi berbasis penguraian IL yang menghindari keharusan menduplikasi nama parameter dalam sebuah string.

Misalnya:

Enforce.Arguments(() => controller, () => viewManager,() => workspace);

Akan memunculkan pengecualian dengan nama parameter yang sesuai jika salah satu argumen yang terdaftar adalah null. Ia juga memiliki penerapan aturan berbasis kebijakan yang sangat rapi.

e.g.

Enforce.Argument(() => username,    StringIs.Limited(3, 64), StringIs.ValidEmail);

Preferensi saya adalah hanya mengevaluasi kondisi dan meneruskan hasilnya daripada meneruskan ekspresi untuk dievaluasi dan parameter untuk mengevaluasinya. Selain itu, saya lebih suka memiliki kemampuan untuk menyesuaikan keseluruhan pesan. Perhatikan bahwa ini hanyalah preferensi -- saya tidak mengatakan bahwa sampel Anda salah -- namun ada beberapa kasus di mana ini sangat berguna.

Helper.Validate( firstName != null || !string.IsNullOrEmpty(directoryID),
                 "The value for firstName cannot be null if a directory ID is not supplied." );

Tidak tahu apakah teknik ini ditransfer dari C/C++ ke C#, tapi saya sudah melakukannya dengan makro:

    #define CHECK_NULL(x)  { (x) != NULL || \
           fprintf(stderr, "The value of %s in %s, line %d is null.\n", \
           #x, __FILENAME__, __LINE__); }
 

Dalam hal ini, daripada menggunakan tipe pengecualian Anda sendiri, atau tipe yang sangat umum seperti ApplicationException.. Saya rasa yang terbaik adalah menggunakan tipe pengecualian bawaan yang khusus ditujukan untuk penggunaan ini:

Diantaranya.. System.ArgumentException, System.ArgumentNullException...

Postsharp atau AOP kerangka kerja.

Ini tidak berlaku di semua tempat, tetapi mungkin membantu dalam banyak kasus:

Saya kira "SomeMethod" sedang melakukan beberapa operasi perilaku pada data "nama belakang", "nama depan" dan "usia". Evaluasi desain kode Anda saat ini. Jika ketiga bagian data membutuhkan satu kelas, masukkan ke dalam satu kelas. Di kelas itu Anda juga dapat memberikan cek Anda. Ini akan membebaskan "SomeMethod" dari pemeriksaan input.

Hasil akhirnya akan menjadi seperti ini:

public void SomeMethod(Person person)
{
    person.CheckInvariants();
    // code here ...
}

Panggilannya akan seperti ini (jika Anda menggunakan .NET 3.5):

SomeMethod(new Person { FirstName = "Joe", LastName = "White", Age = 12 });

dengan asumsi bahwa kelasnya akan terlihat seperti ini:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }

    public void CheckInvariants()
    {
        assertNotNull(FirstName, "first name");
        assertNotNull(LastName, "last name");
    }

    // here are your checks ...
    private void assertNotNull(string input, string hint)
    {
        if (input == null)
        {
            string message = string.Format("The given {0} is null.", hint);
            throw new ApplicationException(message);
        }
    }

Alih-alih gula sintaksis .NET 3.5 Anda juga dapat menggunakan argumen konstruktor untuk membuat objek Person.

Sebaliknya, ini diposkan oleh Miško Hevery di Blog Pengujian Google berpendapat bahwa pemeriksaan parameter semacam ini mungkin tidak selalu merupakan hal yang baik. Perdebatan yang muncul dalam komentar tersebut juga memunculkan beberapa poin menarik.