ไวยากรณ์ที่ราบรื่นและน่าดึงดูดที่สุดที่คุณพบในการยืนยันความถูกต้องของพารามิเตอร์ใน c# คืออะไร

สิ่งนี้อาจเป็นประโยชน์บ้าง:

ออกแบบโดยสัญญา/C# 4.0/หลีกเลี่ยง ArgumentNullException

คุณควรตรวจสอบ สัญญารหัส; พวกเขาทำสิ่งที่คุณถามค่อนข้างทุกประการ ตัวอย่าง:

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

ว้าว ฉันพบสิ่งที่น่าสนใจจริงๆ ที่นี่ Chris ด้านบนให้ลิงก์ไปยังคำถาม Stack Overflow อื่น หนึ่งในคำตอบนั้นชี้ไปที่โพสต์บล็อกซึ่งอธิบายวิธีรับโค้ดดังนี้:

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];
}

ฉันยังไม่มั่นใจว่านี่เป็นคำตอบที่ดีที่สุด แต่ก็น่าสนใจอย่างแน่นอน นี่คือโพสต์ในบล็อก , จากริค บรูว์สเตอร์.

ฉันจัดการกับปัญหาตรงนี้เมื่อสองสามสัปดาห์ก่อน หลังจากที่คิดว่ามันแปลกที่ไลบรารีการทดสอบดูเหมือนจะต้องการ Assert เวอร์ชันที่แตกต่างกันหลายล้านเวอร์ชันเพื่อทำให้ข้อความอธิบายได้

นี่คือวิธีแก้ปัญหาของฉัน

สรุปโดยย่อ - รับโค้ดเล็กน้อยนี้:

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

ฟังก์ชัน Assert ของฉันสามารถพิมพ์ข้อมูลสรุปของสิ่งที่ส่งผ่านไปได้ดังต่อไปนี้:

(((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"
      }
    }
  }
}

ดังนั้นชื่อและค่าของตัวระบุทั้งหมด และโครงสร้างของนิพจน์ จึงสามารถรวมไว้ในข้อความแสดงข้อยกเว้นได้โดยที่คุณไม่ต้องระบุซ้ำในสตริงที่ยกมา

เอาล่ะ ทุกคน ฉันอีกแล้ว และฉันพบสิ่งอื่นที่น่าอัศจรรย์และน่ายินดี เป็นอีกหนึ่งบล็อกโพสต์ที่อ้างอิงมาจากคำถาม SO อื่น ๆ ที่ Chris กล่าวถึงข้างต้น

วิธีการของผู้ชายคนนี้ให้คุณเขียนสิ่งนี้:

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

            // Bootstrap the server
        }
    }

โปรดทราบว่าไม่มีสตริงที่มี "rootDirectory" และไม่มีสตริงที่มี "serverName"!! แต่ข้อความแสดงข้อผิดพลาดของเขาสามารถพูดบางอย่างเช่น "พารามิเตอร์ rootDirectory ต้องไม่เป็นค่าว่าง"

นี่คือสิ่งที่ฉันต้องการและมากกว่าที่ฉันหวังไว้ นี่คือลิงก์ไปยังโพสต์บนบล็อกของชายหนุ่ม

และการนำไปปฏิบัตินั้นค่อนข้างง่ายดังนี้:

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);
        }
    }

โปรดทราบว่าวิธีนี้ใช้ "การสะท้อนแบบคงที่" ดังนั้นในการวนซ้ำที่แน่นหนาหรือบางอย่าง คุณอาจต้องการใช้แนวทางของ Rick Brewster ข้างต้น

ทันทีที่ฉันโพสต์สิ่งนี้ ฉันจะโหวตให้คริสและการตอบคำถาม SO อีกข้อหนึ่ง นี่คือสิ่งดีๆ!!!

การใช้ห้องสมุดของฉัน The Helper Trinity:

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

    ...
}

นอกจากนี้ยังสนับสนุนการยืนยันว่าพารามิเตอร์การแจงนับถูกต้อง คอลเลกชันและเนื้อหาไม่ใช่ null พารามิเตอร์สตริงไม่ว่างเปล่า ฯลฯ ดูเอกสารประกอบผู้ใช้ที่นี่ สำหรับตัวอย่างโดยละเอียด .

นี่คือคำตอบของฉันสำหรับปัญหา ฉันเรียกมันว่า "Guard Claws" มันใช้ตัวแยกวิเคราะห์ IL จาก Lokad Shared Libs แต่มีแนวทางที่ตรงไปตรงมามากกว่าในการระบุส่วนคำสั่งการป้องกันจริง:

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

คุณสามารถดูตัวอย่างการใช้งานเพิ่มเติมได้ในspecs .

เนื่องจากมันใช้แลมบ์ดาจริงเป็นอินพุตและใช้ IL Parser เพื่อสร้างข้อยกเว้นในกรณีของการละเมิดเท่านั้น จึงควรทำงานได้ดีกว่าบน "เส้นทางที่มีความสุข" มากกว่าการออกแบบที่ใช้ Expression ที่อื่นในคำตอบเหล่านี้

ลิงก์ใช้งานไม่ได้ นี่คือ URL: http://github.com/littlebits/guard_claws/

ไลบรารีที่ใช้ร่วมกันของ Lokad ยังมีการดำเนินการตามการแยกวิเคราะห์ IL ซึ่งหลีกเลี่ยงการทำซ้ำชื่อพารามิเตอร์ในสตริง

ตัวอย่างเช่น:

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

จะส่งข้อยกเว้นด้วยชื่อพารามิเตอร์ที่เหมาะสมหากอาร์กิวเมนต์ใด ๆ ที่ระบุไว้เป็นโมฆะ นอกจากนี้ยังมีการใช้กฎตามนโยบายที่ประณีตจริงๆ

e.g.

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

ความชอบของฉันคือเพียงประเมินเงื่อนไขและส่งผลลัพธ์ แทนที่จะส่งนิพจน์ที่จะประเมินและพารามิเตอร์ที่จะประเมิน นอกจากนี้ ฉันชอบที่จะมีความสามารถในการปรับแต่งข้อความทั้งหมด โปรดทราบว่าสิ่งเหล่านี้เป็นเพียงการตั้งค่า -- ฉันไม่ได้บอกว่าตัวอย่างของคุณผิด แต่มีบางกรณีที่สิ่งนี้มีประโยชน์มาก

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

ไม่รู้ว่าเทคนิคนี้ถ่ายโอนจาก C/C++ ไปเป็น C# หรือไม่ แต่ฉันได้ทำสิ่งนี้ด้วยมาโคร:

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

ในกรณีนี้ แทนที่จะใช้ประเภทข้อยกเว้นของคุณเองหรือประเภททั่วไปเช่น ApplicationException... ฉันคิดว่าเป็นการดีที่สุดที่จะใช้ประเภทข้อยกเว้นในตัวที่มีไว้สำหรับการใช้งานนี้โดยเฉพาะ:

ในบรรดาเหล่านั้น .. System.ArgumentException, System.ArgumentNullException...

Postsharp หรือ AOP เฟรมเวิร์ก.

ไม่สามารถใช้ได้กับทุกที่ แต่อาจช่วยได้ในหลายกรณี:

ฉันคิดว่า "SomeMethod" กำลังดำเนินการตามพฤติกรรมบางอย่างกับข้อมูล "นามสกุล" "ชื่อ" และ "อายุ" ประเมินการออกแบบโค้ดปัจจุบันของคุณ หากข้อมูลทั้งสามชิ้นกำลังร้องขอชั้นเรียน ให้จัดข้อมูลเหล่านั้นไว้ในชั้นเรียน ในชั้นเรียนนั้นคุณสามารถใส่เช็คได้เช่นกัน สิ่งนี้จะทำให้ "SomeMethod" ว่างจากการตรวจสอบอินพุต

ผลลัพธ์ที่ได้จะเป็นดังนี้:

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

การโทรจะเป็นดังนี้ (ถ้าคุณใช้ .NET 3.5):

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

ภายใต้สมมติฐานว่าชั้นเรียนจะเป็นดังนี้:

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);
        }
    }

แทนที่จะใช้น้ำตาลวากยสัมพันธ์ของ .NET 3.5 คุณยังสามารถใช้อาร์กิวเมนต์ตัวสร้างเพื่อสร้างวัตถุบุคคลได้

ในทางตรงกันข้าม สิ่งนี้ โพสต์โดย Miško Hevery บน บล็อกการทดสอบของ Google แย้งว่าการตรวจสอบพารามิเตอร์ประเภทนี้อาจไม่ใช่สิ่งที่ดีเสมอไป ผลการถกเถียงในความคิดเห็นยังทำให้เกิดประเด็นที่น่าสนใจอีกด้วย