คำถามติดแท็ก exception-handling

การจัดการข้อยกเว้นเป็นกระบวนการของการตอบสนองต่อการเกิดขึ้นของเงื่อนไขที่ผิดปกติหรือพิเศษที่ต้องการการประมวลผลพิเศษ - มักจะเปลี่ยนการไหลปกติของการทำงานของโปรแกรม

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

10
ทำไมไม่ใช้คำว่า bug แทนการยกเว้น? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา หากเราอ้างถึงข้อยกเว้นว่าเป็นข้อบกพร่องทำไมไม่เรียกมันว่าบั๊กตั้งแต่แรกแทนที่จะเป็นข้อยกเว้น? หากในรหัสเรียกว่าข้อยกเว้นและทันทีที่มันเกิดขึ้นจะเรียกว่าข้อผิดพลาด ถ้าอย่างนั้นทำไมไม่เรียกมันว่าบั๊กในตอนแรกล่ะ? ขอบคุณสำหรับคำตอบหรือความคิดเห็น

3
การตัดสินใจสำหรับข้อยกเว้นที่ไม่ได้ตรวจสอบใน Scala
ในฐานะโปรแกรมเมอร์ Java ฉันมีความสำคัญอย่างยิ่งต่อข้อยกเว้นที่ไม่ได้ตรวจสอบ โปรแกรมเมอร์ส่วนใหญ่ใช้เป็นเส้นทางในการเข้ารหัสความง่ายเท่านั้นเพื่อสร้างปัญหาในภายหลัง นอกจากนี้โปรแกรม (แม้ว่าจะไม่เป็นระเบียบ) ที่มีข้อยกเว้นที่ตรวจสอบนั้นมีความแข็งแกร่งมากเมื่อเปรียบเทียบกับโปรแกรมที่ไม่ได้ตรวจสอบ น่าแปลกที่ Scala ไม่มีสิ่งใดที่เรียกว่าข้อยกเว้นที่ตรวจสอบแล้ว Java ที่เลือกและไม่ถูกตรวจสอบทั้งหมดจะถูกตรวจสอบใน Scala แรงจูงใจในการตัดสินใจครั้งนี้คืออะไร? สำหรับฉันมันเปิดปัญหามากมายเมื่อใช้รหัสภายนอกใด ๆ และถ้าโดยบังเอิญเอกสารไม่ดีก็จะส่งผลให้ฆ่า

2
บทคัดย่อยกเว้นชนิดซุปเปอร์
หากการขว้างปาSystem.Exceptionถือว่าแย่มากทำไมไม่Exceptionทำabstractในตอนแรก? ด้วยวิธีนี้มันเป็นไปไม่ได้ที่จะโทร: throw new Exception("Error occurred."); สิ่งนี้จะบังคับใช้การยกเว้นที่ได้รับเพื่อให้รายละเอียดเพิ่มเติมเกี่ยวกับข้อผิดพลาดที่เกิดขึ้น ตัวอย่างเช่นเมื่อฉันต้องการให้ลำดับชั้นข้อยกเว้นที่กำหนดเองสำหรับห้องสมุดฉันมักจะประกาศคลาสฐานนามธรรมสำหรับข้อยกเว้นของฉัน: public abstract class CustomExceptionBase : Exception { /* some stuff here */ } แล้วมีข้อยกเว้นบางอย่างที่มีจุดประสงค์เฉพาะเจาะจงมากขึ้น: public class DerivedCustomException : CustomExceptionBase { /* some more specific stuff here */ } จากนั้นเมื่อเรียกเมธอดไลบรารี่ใด ๆ เราสามารถลอง / แทร็กบล็อคทั่วไปเพื่อดักจับข้อผิดพลาดที่มาจากไลบรารีโดยตรง: try { /* library calls here */ } catch …

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

1
มันเป็นเรื่องปกติไหมที่จะใช้ตัวสร้างปริยาย
ถามเฉพาะเกี่ยวกับตัวสร้างเริ่มต้น ระบุว่าตัวสร้างเริ่มต้นข้อมูลทั้งหมดสำหรับวัตถุถ้าฉันสร้างคลาสที่ไม่สามารถใช้โดยไม่ต้องเริ่มต้นที่เหมาะสมมันไม่ใช่กรณีที่นวกรรมิกเริ่มต้นไม่มีประโยชน์หรือไม่ พิจารณา: // A class for handling lines in a CSV file class CSV_Entry { private: unsigned num_entries; std::string string_version; std::vector<std::string> vector_version; ...etc public: CSV_Entry(); CSV_Entry(const std::string& src_line); // returns a vector copy of the original entry std::vector<std::string> get_vector_snapshot(); } int main( void ) { ...etc CSV_Entry example = …

6
ทางเลือกในการลองจับซ้อนสำหรับทางเลือก
ฉันมีสถานการณ์ที่ฉันพยายามดึงวัตถุ หากการค้นหาล้มเหลวฉันมีข้อผิดพลาดหลายประการซึ่งแต่ละข้ออาจล้มเหลว ดังนั้นรหัสดูเหมือนว่า: try { return repository.getElement(x); } catch (NotFoundException e) { try { return repository.getSimilarElement(x); } catch (NotFoundException e1) { try { return repository.getParentElement(x); } catch (NotFoundException e2) { //can't recover throw new IllegalArgumentException(e); } } } มันดูน่าเกลียดมาก ๆ ฉันเกลียดที่จะคืนค่าว่าง แต่ในสถานการณ์นี้ดีกว่าไหม Element e = return repository.getElement(x); if (e == …

5
การจัดการข้อยกเว้นในโปรแกรมที่ต้องการเรียกใช้ 24/7
ฉันได้อ่านแล้วว่าเราควรจะจับข้อยกเว้นที่สามารถจัดการได้ซึ่งทำให้การจับคลาสยกเว้นฐาน (C # ในกรณีนี้) เป็นความคิดที่ไม่ดี (ด้วยเหตุผลอื่น) ปัจจุบันฉันเป็นส่วนหนึ่งของโครงการที่ฉันยังไม่เห็นอะไรเลยนอกจากข้อยกเว้นพื้นฐานที่ถูกจับได้ ฉันบอกว่ามันถือว่าเป็นการปฏิบัติที่ไม่ดี แต่การตอบสนองคือ "บริการนี้ต้องทำงานตลอด 24/7 ดังนั้นนี่คือวิธีที่มันเป็น" เนื่องจากฉันไม่ได้รับการตอบรับที่ดีสำหรับวิธีการจัดการข้อยกเว้นในโปรแกรมที่ต้องการเรียกใช้ 24/7 อย่างถูกต้องฉันจึงมาที่นี่ ฉันไม่ได้หาข้อมูล / คำแนะนำเกี่ยวกับวิธีจัดการกับการจัดการข้อยกเว้นในโปรแกรม / บริการ "วิกฤติ" ที่ต้องทำงานตลอดเวลา (และในกรณีนี้ฉันเชื่อว่ามันอาจใช้ได้ถ้าบริการหยุดทำงานเป็นเวลาหนึ่งนาที หรือสองจึงไม่สำคัญ) ฉันเข้าใจว่ามันขึ้นอยู่กับลักษณะที่แน่นอนของโปรแกรม ข้อกำหนดสำหรับโปรแกรมที่อาจทำให้เกิดปัญหาการคุกคามต่อชีวิตแตกต่างกันมากเมื่อเทียบกับเครื่องสแกนบันทึกสำหรับเกมออนไลน์ สองตัวอย่าง: 1: บริการพิมพ์ล่วงหน้าสำหรับลูกค้าของรถไฟ Brittish ใช้เมื่อค้นหาออนไลน์สำหรับสถานีรถไฟ 2: โปรแกรมที่ควบคุมสวิตช์รถไฟสำหรับรถไฟเหนือโดยอัตโนมัติตามข้อมูลเรียลไทม์ที่ได้รับจากเซ็นเซอร์ต่าง ๆ ในแทร็ครถไฟ ฯลฯ โปรแกรมแรกอาจไม่ทำให้เกิดปัญหาใหญ่หากลงไปหนึ่งหรือสองนาทีขณะที่หลังอาจทำให้เกิดการบาดเจ็บล้มตายของมนุษย์ ข้อเสนอแนะเกี่ยวกับวิธีการจัดการกับแต่ละคน? ชี้ไปที่ที่ฉันสามารถหาข้อมูลและความคิดเพิ่มเติมเกี่ยวกับปัญหานี้ได้หรือไม่

3
แนะนำรูปแบบการออกแบบ / แนวทางในการเปิดเผย / ยอมรับ / กู้คืนจากข้อผิดพลาดของระบบการจัดการข้อยกเว้น (egs ใน Java, C ++, Perl, PHP)
คุณสามารถแนะนำรูปแบบการออกแบบ / แนวทางในการเปิดเผย / ยอมรับ / กู้คืนจากข้อผิดพลาดของระบบการจัดการข้อยกเว้น (Java, C ++, Perl, PHP) หรือไม่ จำเป็นต้องรายงานข้อผิดพลาดบางอย่าง ข้อผิดพลาดบางอย่างสามารถจัดการภายใน (โดยลองใหม่หรือไม่สำคัญ (สามารถเพิกเฉย) คุณจัดโครงสร้างรหัสเพื่อจับพวกเขาอย่างไร แต่จะต้องมีการบันทึกข้อผิดพลาดทั้งหมด มีแนวทางปฏิบัติที่ดีที่สุดอะไรบ้าง และสำหรับการจำลองพวกเขาเพื่อให้สามารถทดสอบส่วนประกอบที่ได้รับผลกระทบโดยสมบูรณ์ได้ คำถามเฉพาะที่ไม่ใช่ภาษาโปรแกรมทั่วไปที่ใช้กับภาษาการเขียนโปรแกรมสมัยใหม่หลายภาษา แต่ยินดีต้อนรับตัวอย่างภาพประกอบของรูปแบบวิธีการและปรัชญาใน Java, C ++, PHP และ Perl (ถามด้วยใน stackoverflow: /programming/7432596/recommend-a-design-pattern-approach-to-exposing-tolerating-recovering-from-system) แต่ฉันคิดว่ามันควรถามโปรแกรมเมอร์เช่นกัน ฉันคิดว่าโปรแกรมเมอร์ถาม - ตอบครอบคลุมถึงซอฟต์แวร์ / ปัญหาการเขียนโปรแกรมที่กว้างขึ้น

2
ฉันจะจัดการกับความล้มเหลวของคนตัดไม้ได้อย่างไร
ในหลายแอปพลิเคชันของ บริษัท เราใช้ตัวบันทึกที่กำหนดเอง มันค่อนข้างแข็งแกร่งแม้ว่าเราอาจแทนที่ด้วยอะไรบางอย่างเช่น NLog ในอนาคต หนึ่งในหน้าที่ของคนตัดไม้คือการบันทึกข้อยกเว้นที่พบในแอปพลิเคชัน สิ่งหนึ่งที่ฉันกังวลอยู่เสมอคือการจัดการข้อยกเว้นภายในตัวบันทึกช่วยให้เกิดความล้มเหลวเงียบ นั่นคือถ้าบันทึกไม่ได้ถูกเขียนสำหรับข้อยกเว้นที่กำหนด (เนื่องจากข้อผิดพลาดในตัวบันทึก) ฉันจะจัดการกับมันอย่างไรและ (อย่างใด) บันทึกข้อยกเว้นในตัวบันทึกเอง ? สมมติว่าฟังก์ชัน WriteLog ส่งข้อยกเว้น ฉันควรลองเรียกใช้ฟังก์ชันบางครั้งหรือจนกว่าจะมีข้อผิดพลาดเกิดขึ้น? ฉันควรลองเขียนข้อยกเว้นที่โยนด้วยตัวบันทึก (ซึ่งน่าจะส่งผลให้เกิดข้อยกเว้นลงไปหมด ... ) ฉันโชคดีที่ไม่พบสถานการณ์นี้ยกเว้นตอนที่เราใช้งานตัวบันทึกที่กำหนดเองเป็นครั้งแรก ในทางกลับกันฉันไม่มีทางรู้ได้เลยว่าคนตัดไม้ล้มเหลวในการบันทึกข้อยกเว้นแอปพลิเคชัน (เนื่องจากข้อยกเว้นของตัวเอง) ฉันได้ลองค้นหาทางออนไลน์และในเว็บไซต์ SE บางแห่ง แต่มันก็ยังไม่เกิดผลดีนักเนื่องจากการโพสต์ทั้งหมดมีข้อผิดพลาดในตัวบันทึก (แต่ไม่ใช่ข้อยกเว้นที่เป็นไปได้และวิธีการบันทึก) หรือข้อยกเว้นภายนอกตัวบันทึก

5
การเสริมความแข็งแกร่งโค้ดด้วยการจัดการข้อยกเว้นที่ไร้ประโยชน์อาจเป็นไปได้
เป็นวิธีปฏิบัติที่ดีที่จะใช้การจัดการข้อยกเว้นที่ไร้ประโยชน์หรือไม่ในกรณีที่ส่วนอื่นของรหัสไม่ได้เข้ารหัสอย่างถูกต้อง? ตัวอย่างพื้นฐาน คนที่เรียบง่ายดังนั้นฉันจึงไม่สูญเสียทุกคน :) สมมติว่าฉันกำลังเขียนแอพที่จะแสดงข้อมูลของบุคคล (ชื่อที่อยู่ ฯลฯ ) ข้อมูลที่ถูกแยกออกจากฐานข้อมูล สมมติว่าฉันเป็นผู้เขียนส่วน UI และคนอื่นกำลังเขียนรหัสแบบสอบถาม DB ทีนี้ลองจินตนาการว่าข้อมูลจำเพาะของแอพของคุณบอกว่าถ้าข้อมูลของบุคคลนั้นไม่สมบูรณ์ (สมมติว่าชื่อหายไปในฐานข้อมูล) ผู้ที่เข้ารหัสแบบสอบถามควรจัดการสิ่งนี้โดยส่งกลับ "NA" สำหรับฟิลด์ที่หายไป เกิดอะไรขึ้นถ้าแบบสอบถามมีการเข้ารหัสไม่ดีและไม่จัดการกรณีนี้ จะเป็นอย่างไรถ้าคนที่เขียนข้อความค้นหาจัดการกับผลลัพธ์ที่ไม่สมบูรณ์และเมื่อคุณพยายามที่จะแสดงข้อมูลทุกอย่างก็ขัดข้องเพราะรหัสของคุณไม่ได้เตรียมที่จะแสดงสิ่งที่ว่างเปล่า? ตัวอย่างนี้เป็นพื้นฐานมาก ฉันเชื่อว่าพวกคุณส่วนใหญ่จะพูดว่า "ไม่ใช่ปัญหาของคุณคุณไม่ต้องรับผิดชอบต่อความผิดพลาดนี้" แต่ก็ยังคงเป็นส่วนหนึ่งของรหัสของคุณที่ขัดข้อง ตัวอย่างอื่น สมมติว่าตอนนี้ฉันเป็นคนเขียนแบบสอบถาม ข้อกำหนดไม่ได้พูดเหมือนกับข้างต้น แต่คนที่เขียนแบบสอบถาม "แทรก" ควรตรวจสอบให้แน่ใจว่าเขตข้อมูลทั้งหมดจะเสร็จสมบูรณ์เมื่อเพิ่มบุคคลในฐานข้อมูลเพื่อหลีกเลี่ยงการแทรกข้อมูลที่ไม่สมบูรณ์ ฉันควรจะปกป้องแบบสอบถาม "เลือก" ของฉันเพื่อให้แน่ใจว่าฉันให้ข้อมูลที่สมบูรณ์เกี่ยวกับ UI หรือไม่ คำถาม ถ้าข้อมูลจำเพาะไม่ได้พูดอย่างชัดเจนว่า "คนนี้เป็นคนที่รับผิดชอบในการจัดการสถานการณ์นี้"? ถ้าบุคคลที่สามใช้แบบสอบถามอื่น (คล้ายกับแบบสอบถามแรก แต่ใช้ฐานข้อมูลอื่น) และใช้รหัส UI ของคุณเพื่อแสดง แต่ไม่จัดการกรณีนี้ในรหัสของเขา ฉันควรทำสิ่งที่จำเป็นเพื่อป้องกันความผิดพลาดที่อาจเกิดขึ้นแม้ว่าฉันจะไม่ใช่คนที่ควรจัดการกับคดีที่ไม่ดี? ฉันไม่ได้มองหาคำตอบเช่น "(s) เขาเป็นคนรับผิดชอบต่อความผิดพลาด" เนื่องจากฉันไม่ได้แก้ไขข้อขัดแย้งที่นี่ฉันอยากรู้ว่าฉันควรป้องกันโค้ดของฉันจากสถานการณ์ที่ไม่ใช่ความรับผิดชอบของฉันหรือไม่ …

1
ข้อยกเว้นการปฏิบัติหรือคำแนะนำที่ดีที่สุด [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ฉันคิดว่าปัญหาหลักสองประการของโปรแกรมของฉันคือโครงสร้างรหัส / องค์กรและการจัดการข้อผิดพลาดของฉัน ฉันกำลังอ่าน Code Complete 2 แต่ฉันต้องการอ่านเพื่อทำงานกับปัญหาที่อาจเกิดขึ้น ตัวอย่างเช่นบนเว็บไซต์หากบางสิ่งสามารถเกิดขึ้นได้เฉพาะเมื่อผู้ใช้ tampers กับข้อมูลผ่านทางจาวาสคริปต์คุณเขียนเพื่อที่? นอกจากนี้เมื่อใดที่คุณไม่พบข้อผิดพลาด? เมื่อคุณเขียนคลาสที่คาดว่าสตริงและ int เป็นอินพุตและพวกเขาไม่ใช่สตริงและ int คุณตรวจสอบสิ่งนั้นหรือไม่หรือคุณปล่อยให้มันลอยไปจนถึงวิธีการโทรที่ผ่านพารามิเตอร์ที่ไม่ถูกต้องหรือไม่ ฉันรู้ว่านี่เป็นหัวข้อกว้าง ๆ ที่ไม่สามารถตอบได้ด้วยคำตอบเดียวที่นี่ดังนั้นสิ่งที่ฉันกำลังมองหาคือหนังสือหรือแหล่งข้อมูลที่ได้รับการยอมรับโดยทั่วไปว่าเป็นการสอนการจัดการข้อยกเว้นที่เหมาะสม

3
“ วิธีการที่ไม่ดี” เป็นรหัสที่ไม่เกี่ยวข้องในการลองจับในที่สุดบล็อก?
นี่คือคำถามที่เกี่ยวข้อง: ในที่สุดการใช้ประโยคในการทำงานหลังจากกลับมาในสไตล์ที่ไม่ดี / เป็นอันตรายหรือไม่? ใน Q อ้างอิงแล้วรหัสสุดท้ายเกี่ยวข้องกับโครงสร้างที่ใช้และความจำเป็นในการดึงข้อมูลล่วงหน้า คำถามของฉันแตกต่างออกไปเล็กน้อยและฉันเชื่อว่ามันเป็นสิ่งที่ดีสำหรับผู้ชมที่กว้างขึ้น ตัวอย่างเฉพาะของฉันคือแอป C # winform แต่สิ่งนี้จะใช้กับ C ++ / Java ในที่สุดการใช้งานเช่นกัน ฉันสังเกตเห็นว่ามีการลองจับสองสามครั้งในที่สุดซึ่งมีโค้ดจำนวนมากที่ไม่เกี่ยวข้องกับข้อยกเว้นและการจัดการ / ล้างข้อมูลที่ฝังอยู่ภายในบล็อก และฉันจะยอมรับความลำเอียงของฉันต่อการพยายามบล็อกที่จับได้แน่นในที่สุดด้วยรหัสที่เกี่ยวข้องกับข้อยกเว้นและการจัดการอย่างใกล้ชิด นี่คือตัวอย่างของสิ่งที่ฉันเห็น ลองบล็อกจะมีการโทรขั้นต้นจำนวนมากและตัวแปรที่ตั้งค่านำไปสู่รหัสที่สามารถโยนได้ ข้อมูลการบันทึกจะได้รับการตั้งค่าและเรียกใช้ในบล็อกลองด้วย ในที่สุดบล็อกจะมีการเรียกการจัดรูปแบบแบบฟอร์ม / โมดูล / การควบคุม (แม้แอพกำลังจะปิดตัวลงดังที่แสดงในบล็อก catch) รวมถึงการสร้างวัตถุใหม่เช่นแผงควบคุม ประมาณ: methodName (... ) { ลอง { // มีโค้ดสำหรับวิธีการมากมาย ... // รหัสที่สามารถส่ง ... // มีโค้ดมากขึ้นสำหรับวิธีการและการส่งคืน ... } …

8
อะไรคือวิธีที่ดีในการปรับสมดุลข้อยกเว้นที่ให้ข้อมูลและรหัสที่สะอาด
ด้วย SDK สาธารณะของเราเรามักจะต้องการส่งข้อความที่ให้ข้อมูลอย่างมากเกี่ยวกับสาเหตุที่เกิดข้อยกเว้น ตัวอย่างเช่น: if (interfaceInstance == null) { string errMsg = string.Format( "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.", ParameterInfo.Name, ParameterInfo.ParameterType, typeof(IParameter) ); throw new InvalidOperationException(errMsg); } อย่างไรก็ตามสิ่งนี้มีแนวโน้มที่จะทำให้การไหลเวียนของรหัสแย่ลงเนื่องจากมีแนวโน้มที่จะให้ความสำคัญกับข้อความแสดงข้อผิดพลาดมากกว่าที่จะทำโค้ด เพื่อนร่วมงานเริ่ม refactoring ข้อยกเว้นบางอย่างให้กับสิ่งนี้: if (interfaceInstance == null) throw …

4
จงใจยกข้อยกเว้นเพื่อใช้ catch
สำหรับแบบทั่วไปที่if...elseมีการจัดการข้อยกเว้นบางอย่างเช่นตัวอย่างต่อไปนี้เป็นแนวทางปฏิบัติที่แนะนำเพื่อหลีกเลี่ยงการทำสำเนารหัสหรือไม่ try { if (GetDataFromServer()) { return ProcessData(); } else { throw new Exception(); } catch(Exception ex) { return null; } แทน... try { if (GetDataFromServer()) { return ProcessData(); } else { return null; } } catch(Exception ex) { return null; } ฉันรู้ว่ามีการแสดงเล็กน้อย แต่ฉันสงสัยว่านี่เป็นการปฏิบัติที่ยอมรับได้หรือไม่ ปัจจุบันฉันใช้วิธีที่สองโดยเฉพาะในกรณีที่ฉันต้องจัดการกับข้อยกเว้นที่แตกต่างกัน - แต่ฉันสงสัยว่าวิธีแรกนั้นเหมาะสมกับกรณีง่ายหรือไม่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.