.NET: ข้อยกเว้นใดที่ควรทิ้งเมื่อการตั้งค่าคอนฟิกที่จำเป็นขาดหายไป?

นี่คือสถานการณ์มาตรฐาน:

if(string.IsNullOrEmpty(Configuration.AppSettings["foobar"]))
   throw new SomeStandardException("Application not configured correctly, bozo.");

ปัญหาคือฉันไม่แน่ใจว่าข้อยกเว้นSomeStandardExceptionใดควรเป็นอย่างยิ่ง

ฉันอ่าน 3.5 Framework และพบผู้สมัครสองคนที่น่าจะเป็น: ConfigurationExceptionและConfigurationErrorsException.

System.Configuration.ConfigurationException

ข้อยกเว้นที่เกิดขึ้นเมื่อเกิดข้อผิดพลาดของระบบคอนฟิกูเรชัน

หมายเหตุ

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

บันทึก:

ConfigurationExceptionวัตถุจะยังคงเข้ากันได้ย้อนหลัง ConfigurationErrorsException วัตถุแทนที่ระบบการกำหนดค่า

ข้อยกเว้นนี้ฟังดูสมบูรณ์แบบสำหรับสิ่งที่ฉันต้องการ แต่ถูกทำเครื่องหมายว่าล้าสมัยดังนั้น ixnay on atthay

สิ่งนี้ทำให้เรางงอย่างละเอียดConfigurationErrorsException:

System.Configuration.ConfigurationErrorsException

ค่าปัจจุบันไม่ใช่หนึ่งในค่า EnableSessionState

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

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

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

แก้ไขภาคผนวก

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

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

คุณไม่ได้ จำกัด ข้อยกเว้นของคุณไว้ที่ข้อยกเว้นที่มีอยู่ใน Framework หากคุณตัดสินใจที่จะใช้ข้อยกเว้นที่มีอยู่คุณไม่จำเป็นต้องปฏิบัติตามเอกสารประกอบของจดหมาย เอกสารประกอบจะอธิบายว่ากรอบงานใช้ข้อยกเว้นที่กำหนดอย่างไร แต่ไม่ได้หมายความถึงข้อ จำกัด ใด ๆ เกี่ยวกับวิธีที่คุณเลือกใช้ / ใช้ข้อยกเว้นที่มีอยู่ซ้ำ

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

[Serializable]
public class ConfigurationMissingException : ConfigurationErrorsException
{}

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

UPDATE: ฉันเห็นด้วยกับความคิดเห็นดังนั้นฉันจึงเปลี่ยนคลาสย่อยเป็น ConfigurationErrorsException จาก Exception ฉันคิดว่าโดยทั่วไปแล้วเป็นความคิดที่ดีที่จะใช้ข้อยกเว้นแบบกำหนดเองของคลาสย่อยจากข้อยกเว้นของ Framework ที่มีอยู่หากเป็นไปได้หลีกเลี่ยงคลาส Exception เว้นแต่คุณจะต้องการข้อยกเว้นเฉพาะแอปพลิเคชัน

โดยส่วนตัวฉันใช้InvalidOperationExceptionเนื่องจากมีปัญหากับสถานะวัตถุไม่ใช่ระบบการกำหนดค่า ท้ายที่สุดคุณไม่ควรอนุญาตให้ตั้งค่าเหล่านี้ด้วยรหัสและไม่กำหนดค่าด้วยหรือไม่? ส่วนสำคัญที่นี่ไม่ใช่ว่าไม่มีบรรทัดใน app.config แต่ไม่มีข้อมูลที่ต้องการ

สำหรับฉัน ConfigurationException (และเป็นการแทนที่ ConfigurationErrorsException - แม้ว่าเอกสาร MSDN ที่ทำให้เข้าใจผิด) เป็นข้อผิดพลาดในการบันทึกการอ่านและอื่น ๆ ของ Configuration

ดังที่ Daniel Richardson กล่าวว่าConfigurationErrorsExceptionเป็นสิ่งที่ต้องใช้ โดยทั่วไปขอแนะนำให้สร้างประเภท Exception ที่กำหนดเองเท่านั้นหากคุณมีสถานการณ์ที่ต้องจัดการ ในกรณีของข้อผิดพลาดในการกำหนดค่าซึ่งมักเป็นอันตรายถึงชีวิตมักไม่ค่อยเกิดขึ้นดังนั้นจึงเหมาะสมกว่าที่จะใช้ประเภท ConfigurationErrorsException ที่มีอยู่ซ้ำ

ก่อนที่จะ .NET 2.0 ข้อเสนอแนะคือการใช้System.Configuration.ConfigurationException ConfigurationException ล้าสมัยใน. NET 2.0 ด้วยเหตุผลที่ไม่เคยชัดเจนสำหรับฉันและคำแนะนำเปลี่ยนไปใช้ ConfigurationErrorsException

ฉันใช้วิธีผู้ช่วยในการโยนข้อยกเว้นเพื่อให้ง่ายต่อการเปลี่ยนข้อยกเว้นที่ถูกโยนทิ้งในที่เดียวเมื่อย้ายจาก. NET 1.x เป็น 2.0 หรือถ้า Microsoft ตัดสินใจเปลี่ยนคำแนะนำอีกครั้ง:

if(string.IsNullOrEmpty(Configuration.AppSettings("foobar")))
{
   throw CreateMissingSettingException("foobar");
}

...

private static Exception CreateMissingSettingException(string name)
{
    return new ConfigurationErrorsException(
        String.Format
        (
        CultureInfo.CurrentCulture,
        Properties.Resources.MissingConfigSetting,
        name
        )
        );
}

เกี่ยวกับอะไรSystem.Configuration.SettingsPropertyNotFoundException?

ConfigurationErrorsExceptionเป็นข้อยกเว้นที่ถูกต้องสำหรับสถานการณ์ที่คุณอธิบาย เอกสาร MSDN เวอร์ชันก่อนหน้าเพื่อConfigurationErrorsExceptionให้เหมาะสมยิ่งขึ้น

http://msdn.microsoft.com/en-us/library/system.configuration.configurationerrorsexception(VS.80).aspx

สรุปและข้อสังเกต MSDN ก่อนหน้านี้คือ:

• ข้อยกเว้นที่เกิดขึ้นเมื่อเกิดข้อผิดพลาดของระบบคอนฟิกูเรชัน
• ConfigurationErrorsException ยกเว้นจะโยนเมื่อข้อผิดพลาดใด ๆ เกิดขึ้นในขณะที่ข้อมูลการกำหนดค่าจะถูกอ่านหรือเขียน

คลาส ConfigurationElement (ซึ่งเป็นคลาสพื้นฐานของคลาสที่เกี่ยวข้องกับการกำหนดค่าจำนวนมากเช่น ConfigurationSection) มีเมธอดที่เรียกว่า OnRequiredPropertyNotFound (มีวิธีการช่วยเหลืออื่น ๆ ด้วย) คุณสามารถโทรหาสิ่งเหล่านั้นได้

OnRequiredPropertyNotFound ถูกนำไปใช้เช่นนี้:

protected virtual object OnRequiredPropertyNotFound(string name) {
    throw new ConfigurationErrorsException(SR.GetString("Config_base_required_attribute_missing", new object[] { name }), this.PropertyFileName(name), this.PropertyLineNumber(name)); }

ฉันจะดูดมันขึ้นมาแล้วม้วนเอง ... แต่ก่อนที่จะทำเป็นไปได้ไหมที่ระบบจะถือว่าค่าเริ่มต้นสำหรับการตั้งค่าคอนฟิกนี้ โดยทั่วไปฉันจะพยายามทำเช่นนั้นสำหรับทุกการตั้งค่าที่อาจทำให้พลาด bu Ops Management folk ... .. )

โดยทั่วไปข้อยกเว้นที่กำหนดเองไม่ใช่ความพยายามมากนัก ... นี่คือตัวอย่าง ...

[Serializable]
public class MyCustomApplicationException : ApplicationException
{
    #region privates
    #endregion privates

    #region properties
    #endregion properties

    public MyCustomApplicationException (string sMessage,
        Exception innerException)
        : base(sMessage, innerException) { }
    public MyCustomApplicationException (string sMessage)
        : base(sMessage) { }
    public MyCustomApplicationException () { }

    #region Serializeable Code
    public MyCustomApplicationException (
       SerializationInfo info, StreamingContext context)
        : base(info, context) { }
    #endregion Serializeable Code
}

วิธีทางเลือกที่คุณสามารถใช้สำหรับการ config AppSettingsไฟล์ของคุณจะใช้ส่วนกำหนดค่าที่กำหนดเองเมื่อเทียบกับ ด้วยวิธีนี้คุณสามารถระบุว่าคุณสมบัติIsRequiredและระบบคอนฟิกูเรชันจะจัดการการตรวจสอบนี้ให้คุณ หากคุณสมบัติหายไปConfigurationErrorsExceptionฉันคิดว่ามันสนับสนุนคำตอบที่คุณควรใช้ข้อยกเว้นนั้นในกรณีของคุณ

กฎทั่วไปของฉันคือ:

1. หากกรณีของการกำหนดค่าที่ขาดหายไปไม่ใช่เรื่องธรรมดาและฉันเชื่อว่าฉันไม่ต้องการจัดการกรณีนี้แตกต่างจากข้อยกเว้นอื่น ๆ ฉันเพียงแค่ใช้คลาส "ข้อยกเว้น" พื้นฐานพร้อมข้อความที่เหมาะสม:

   โยนข้อยกเว้นใหม่ ("ข้อความของฉันที่นี่")

2. หากฉันต้องการหรือคิดว่ามีความเป็นไปได้สูงที่ฉันจะต้องการจัดการกรณีนี้ในลักษณะที่แตกต่างจากข้อยกเว้นอื่น ๆ ส่วนใหญ่ฉันจะม้วนประเภทของตัวเองตามที่มีคนแนะนำไว้แล้วที่นี่

ฉันมักจะไม่เห็นด้วยกับคำถามของคุณ:

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

ตามเอกสาร MSDN เรื่อง System.Exception ( Exception Classจริงๆแล้วคุณไม่ควรทิ้งข้อยกเว้นสำหรับข้อผิดพลาดในการป้อนข้อมูลของผู้ใช้ด้วยเหตุผลด้านประสิทธิภาพ (ซึ่งผู้อื่นชี้ให้เห็นใน Stack Overflow และที่อื่น ๆ ) สิ่งนี้ดูเหมือนจะสมเหตุสมผล ดี - เหตุใดฟังก์ชันของคุณจึงไม่สามารถส่งคืนเท็จได้หากป้อนข้อมูลของผู้ใช้ไม่ถูกต้องจากนั้นให้แอปพลิเคชันออกอย่างสง่างามดูเหมือนว่าจะเป็นปัญหาในการออกแบบมากกว่าแล้วจึงเป็นปัญหาเกี่ยวกับข้อยกเว้นที่จะโยน

ตามที่คนอื่น ๆ ได้ชี้ให้เห็นหากคุณต้องทิ้งข้อยกเว้นไม่ว่าจะด้วยเหตุผลใดก็ตาม - ไม่มีเหตุผลใดที่คุณไม่สามารถกำหนดประเภท Exception ของคุณได้โดยการสืบทอดจาก System.Exception

คุณสามารถลองสืบทอดจากข้อยกเว้น XML หรือเพียงแค่ใช้มัน