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

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

156 exception-handling 

สิ่งนี้เป็นปฏิปักษ์หรือไม่? มันเป็นวิธีปฏิบัติที่ยอมรับได้? try { //do something } catch (Exception e) { try { //do something in the same line, but being less ambitious } catch (Exception ex) { try { //Do the minimum acceptable } catch (Exception e1) { //More try catches? } } }

95 anti-patterns  exception-handling 

try ... catchวิธีที่คลาสสิกในการเขียนโปรแกรมอยู่กับ เมื่อไรที่มันจะเหมาะสมที่จะใช้tryโดยไม่catch? ใน Python ข้อมูลต่อไปนี้ถูกกฎหมายและสมเหตุสมผล: try: #do work finally: #do something unconditional อย่างไรก็ตามรหัสไม่ได้catchอะไรเลย ในทำนองเดียวกันหนึ่งสามารถคิดใน Java มันจะเป็นดังนี้: try { //for example try to get a database connection } finally { //closeConnection(connection) } มันดูดีและทันใดนั้นฉันก็ไม่ต้องกังวลกับข้อยกเว้นประเภทอื่น ๆ ถ้านี่เป็นการฝึกฝนที่ดีการฝึกฝนที่ดีเมื่อไหร่? อีกวิธีหนึ่งคือเหตุผลว่าทำไมนี่ไม่ใช่การปฏิบัติที่ดีหรือไม่ถูกกฎหมาย? (ฉันไม่ได้รวบรวมซอร์สฉันถามเกี่ยวกับมันเนื่องจากอาจเป็นข้อผิดพลาดทางไวยากรณ์สำหรับ Java ฉันตรวจสอบว่า Python รวบรวมแน่นอน) ปัญหาที่เกี่ยวข้องที่ฉันพบคือ: ฉันยังคงเขียนฟังก์ชั่น / วิธีในตอนท้ายของมันจะต้องกลับบางสิ่งบางอย่าง อย่างไรก็ตามอาจอยู่ในสถานที่ที่ไม่ควรไปถึงและต้องเป็นจุดกลับ ดังนั้นแม้ว่าฉันจะจัดการกับข้อยกเว้นข้างต้นฉันยังคงกลับมาNULLหรือสตริงที่ว่างในบางจุดในรหัสที่ไม่สามารถเข้าถึงได้มักจะสิ้นสุดของวิธีการ / ฟังก์ชั่น …

79 java  python  exceptions  exception-handling 

ฉันอ่านรหัสของเพื่อนร่วมงานและพบว่าเขามักจะจับข้อยกเว้นต่าง ๆ และจากนั้นก็โยน 'RuntimeException' แทน ฉันมักจะคิดว่านี่เป็นวิธีปฏิบัติที่ไม่ดีมาก ฉันผิดหรือเปล่า?

70 java  exceptions  exception-handling 

ย้อนกลับไปที่โรงเรียนเมื่อ 10 ปีก่อนพวกเขาสอนให้คุณใช้เครื่องมือระบุข้อยกเว้น เนื่องจากพื้นหลังของฉันเป็นหนึ่งในนั้นโปรแกรมเมอร์ Torvaldish C ที่หลีกเลี่ยงการดื้อ C ++ ยกเว้นว่าถูกบังคับให้ฉันลงเอยด้วยการใช้ C ++ เป็นระยะ ๆ และเมื่อฉันยังคงใช้ตัวระบุข้อยกเว้นเนื่องจากนั่นคือสิ่งที่ฉันได้รับการสอน อย่างไรก็ตามโปรแกรมเมอร์ C ++ ส่วนใหญ่ดูเหมือนจะขมวดคิ้วเมื่อตัวระบุข้อยกเว้น ฉันได้อ่านการอภิปรายและข้อโต้แย้งต่าง ๆ จาก C ++ ผู้เชี่ยวชาญด้านการเช่นนี้ เท่าที่ฉันเข้าใจมันเดือดลงถึงสามสิ่ง: ตัวระบุข้อยกเว้นใช้ระบบชนิดที่ไม่สอดคล้องกับภาษาที่เหลือ ("ระบบชนิดเงา") หากฟังก์ชั่นของคุณที่มีตัวระบุข้อยกเว้นมีข้อผิดพลาดอื่นใดนอกจากสิ่งที่คุณได้ระบุไว้โปรแกรมจะถูกยกเลิกในรูปแบบที่ไม่ดีและไม่คาดคิด ตัวระบุข้อยกเว้นจะถูกลบออกในมาตรฐาน C ++ ที่กำลังจะมาถึง ฉันพลาดอะไรบางอย่างที่นี่หรือนี่คือเหตุผลทั้งหมดเหรอ? ความคิดเห็นของฉัน: เกี่ยวกับ 1): แล้วอะไรล่ะ C ++ อาจเป็นภาษาการเขียนโปรแกรมที่ไม่สอดคล้องกันมากที่สุดที่เคยมีมา เรามีมาโคร, goto / label, horde (hoard?) ของพฤติกรรมที่ไม่ได้กำหนด - / …

50 c++  specifications  exceptions  exception-handling 

ฉันขอขอบคุณฟีเจอร์ Java 8 ใหม่มากมายเกี่ยวกับ lambdas และอินเตอร์เฟสเมธอดดีฟอลต์ แต่ฉันยังคงเบื่อกับข้อยกเว้นที่ตรวจสอบ ตัวอย่างเช่นหากฉันต้องการแสดงรายการเขตข้อมูลที่มองเห็นได้ทั้งหมดของวัตถุที่ฉันต้องการจะเขียนสิ่งนี้: Arrays.asList(p.getClass().getFields()).forEach( f -> System.out.println(f.get(p)) ); แต่เนื่องจากgetวิธีการอาจมีข้อยกเว้นการตรวจสอบซึ่งไม่เห็นด้วยกับConsumerสัญญาอินเตอร์เฟซดังนั้นฉันต้องจับข้อยกเว้นนั้นและเขียนรหัสต่อไปนี้: Arrays.asList(p.getClass().getFields()).forEach( f -> { try { System.out.println(f.get(p)); } catch (IllegalArgumentException | IllegalAccessException ex) { throw new RuntimeException(ex); } } ); อย่างไรก็ตามในกรณีส่วนใหญ่ฉันแค่ต้องการยกเว้นจะถูกโยนเป็นRuntimeExceptionและให้โปรแกรมจัดการหรือไม่ยกเว้นโดยไม่มีข้อผิดพลาดในการรวบรวม ดังนั้นฉันต้องการแสดงความคิดเห็นของคุณเกี่ยวกับวิธีแก้ไขปัญหาการโต้เถียงของฉันสำหรับการตรวจสอบข้อยกเว้นที่น่ารำคาญ ด้วยเหตุนี้ฉันจึงสร้างส่วนต่อประสานConsumerCheckException<T>และฟังก์ชั่นยูทิลิตี้rethrow( อัปเดตตามความต้องการของความคิดเห็นของ Doval ) ดังต่อไปนี้: @FunctionalInterface public interface ConsumerCheckException<T>{ void accept(T elem) throws Exception; …

49 java  functional-programming  exceptions  exception-handling  java8 

ภาษาสมัยใหม่หลายคนให้การจัดการข้อยกเว้นที่อุดมไปด้วยคุณสมบัติ แต่แอปเปิ้ลของการเขียนโปรแกรมภาษาสวิฟท์ไม่ได้ให้กลไกการจัดการข้อยกเว้น ขณะที่ฉันกำลังจมดิ่งอยู่ในข้อยกเว้นฉันมีปัญหาในการคิดสิ่งที่มันหมายถึง Swift มีคำยืนยันและแน่นอนว่ามีค่าตอบแทน แต่ฉันกำลังมีปัญหาในการนึกภาพว่าวิธีคิดตามข้อยกเว้นของฉันทำแผนที่โลกโดยไม่มีข้อยกเว้น (และสำหรับเรื่องนั้นทำไมโลกเช่นนี้เป็นที่น่าพอใจ ) มีสิ่งใดบ้างที่ฉันไม่สามารถทำได้ในภาษาอย่าง Swift ที่ฉันสามารถทำได้ด้วยข้อยกเว้น ฉันจะได้รับบางอย่างจากการสูญเสียข้อยกเว้น? ยกตัวอย่างเช่นฉันจะแสดงสิ่งที่ดีที่สุดได้อย่างไร try: operation_that_can_throw_ioerror() except IOError: handle_the_exception_somehow() else: # we don't want to catch the IOError if it's raised another_operation_that_can_throw_ioerror() finally: something_we_always_need_to_do() ในภาษา (ตัวอย่างเช่น Swift) ที่ไม่มีการจัดการข้อยกเว้น?

47 language-design  exceptions  exception-handling  language-features  swift-language 

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

46 php  object-oriented  exceptions  exception-handling 

คำถามนี้มีวัตถุประสงค์เพื่อนำไปใช้กับภาษาการเขียนโปรแกรม OO ใด ๆ ที่รองรับการจัดการข้อยกเว้น; ฉันใช้ C # เพื่อเป็นตัวอย่างเท่านั้น มักจะมีข้อยกเว้นที่จะยกเมื่อมีปัญหาเกิดขึ้นว่ารหัสไม่สามารถจัดการได้ทันทีและจากนั้นจะถูกจับในcatchประโยคในสถานที่ที่แตกต่างกัน (มักจะเป็นกรอบสแต็คด้านนอก) ถาม:มีสถานการณ์ที่ถูกต้องตามกฎหมายหรือไม่ที่ข้อยกเว้นไม่ได้ถูกโยนทิ้งและจับได้ แต่กลับมาจากวิธีการแล้วส่งผ่านไปเป็นวัตถุข้อผิดพลาดหรือไม่? คำถามนี้เกิดขึ้นสำหรับฉันเพราะSystem.IObserver<T>.OnErrorวิธีของ. NET 4 แนะนำเพียงว่า: ข้อยกเว้นถูกส่งผ่านเป็นวัตถุข้อผิดพลาด ลองดูที่สถานการณ์อื่นการตรวจสอบ สมมติว่าฉันกำลังติดตามภูมิปัญญาดั้งเดิมและดังนั้นฉันจึงแยกแยะระหว่างประเภทวัตถุข้อผิดพลาดIValidationErrorและประเภทข้อยกเว้นแยกValidationExceptionที่ใช้เพื่อรายงานข้อผิดพลาดที่ไม่คาดคิด: partial interface IValidationError { } abstract partial class ValidationException : System.Exception { public abstract IValidationError[] ValidationErrors { get; } } ( System.Component.DataAnnotationsเนมสเปซทำอะไรที่ค่อนข้างคล้ายกัน) ประเภทเหล่านี้สามารถใช้งานได้ดังนี้: partial interface IFoo { } // an …

45 exceptions  exception-handling 

ในภาษาต่าง ๆ (อย่างน้อย Java คิดว่า C #?) คุณสามารถทำสิ่งต่าง ๆ เช่น if( condition ) singleStatement; while( condition ) singleStatement; for( var; condition; increment ) singleStatement; { }ดังนั้นเมื่อผมมีเพียงแค่หนึ่งคำสั่งผมไม่จำเป็นต้องเพิ่มขอบเขตใหม่ที่มี ทำไมฉันถึงลองทำไม่ได้? try singleStatement; catch(Exception e) singleStatement; มีอะไรพิเศษเกี่ยวกับลองจับซึ่งต้องมีขอบเขตใหม่หรือบางสิ่งบางอย่างเสมอ และถ้าเป็นเช่นนั้นคอมไพเลอร์ไม่สามารถแก้ไขได้หรือไม่

38 exception-handling  scope  control-structures 

ตัวอย่าง: foobar = new InputStreamReader(p.getInputStream(), "ISO-8859-1"); เนื่องจากการเข้ารหัสเป็น hardcoded และถูกต้องตัวสร้างจะไม่โยน UnsupportedEncodingException ที่ประกาศในสเปค (ยกเว้นกรณีที่จาวาใช้งานไม่ได้ซึ่งในกรณีนี้ฉันหลงทางอยู่แล้ว) อย่างไรก็ตาม Java บังคับให้ฉันจัดการกับข้อยกเว้นนั้นอยู่ดี ปัจจุบันดูเหมือนว่า try { foobar = new InputStreamReader(p.getInputStream(), "ISO-8859-1"); } catch(UnsupportedEncodingException e) { /* won't ever happen */ } ความคิดใดจะทำให้ดีขึ้นได้อย่างไร

35 java  exception-handling 

ฉันสงสัยว่าอะไรคือข้อดีของMaybe monad ที่มีข้อยกเว้น? ดูเหมือนว่าMaybeเป็นวิธีการทางtry..catchไวยากรณ์ที่ชัดเจน (และค่อนข้างใช้พื้นที่มาก) อัปเดตโปรดทราบว่าฉันตั้งใจจะไม่พูดถึง Haskell

34 language-agnostic  functional-programming  exceptions  exception-handling  monad 

วิเคราะห์รหัส Static เช่นเสริมสร้าง "บ่น" เมื่อมีข้อยกเว้นอาจจะโยนภายในบล็อกบอกว่าfinally Using a throw statement inside a finally block breaks the logical progression through the try-catch-finallyปกติฉันเห็นด้วยกับเรื่องนี้ แต่เมื่อเร็ว ๆ นี้ฉันเจอโค้ดนี้: SomeFileWriter writer = null; try { //init the writer //write into the file } catch (...) { //exception handling } finally { if (writer!= null) writer.close(); } …

27 coding-style  exceptions  exception-handling 

บางภาษา (เช่น C ++ และ PHP เวอร์ชันก่อนหน้า) ไม่รองรับfinallyส่วนของtry ... catch ... finallyโครงสร้าง คือfinallyเคยจำเป็น? เพราะรหัสในมันทำงานอยู่เสมอทำไมฉันจะไม่ / ไม่ควรวางรหัสนั้นหลังจากtry ... catchบล็อกโดยไม่มีส่วนfinallyคำสั่ง? ทำไมต้องใช้ (ฉันกำลังมองหาเหตุผล / แรงบันดาลใจสำหรับการใช้ / ไม่ใช้finallyไม่ใช่เหตุผลที่ต้องทำ 'จับ' หรือทำไมการทำเช่นนั้นถูกกฎหมาย)

25 exception-handling 

ฉันมีเว็บแอพ Spring สามชั้น: dao, บริการและผู้ควบคุม คอนโทรลเลอร์ไม่เคยเรียก dao โดยตรงมันทำผ่านเลเยอร์บริการ ตอนนี้เวลาส่วนใหญ่หากมีข้อยกเว้น dao (รันไทม์) ที่ไม่ได้จัดการมันจะถูกจับโดย JSP แสดงข้อความข้อผิดพลาดให้กับผู้ใช้ ชั้นบริการควรตรวจจับข้อยกเว้น dao ทั้งหมดและตัดเป็นข้อยกเว้นบริการหรือไม่ try { daoInstance.someDaoMethod(); } catch(DataAccessException dae) { throw new ServiceException("message", dae); } สมมติว่า ServiceException นั้นเป็น runtime เช่นกัน มีความแตกต่างใด ๆ เพียงแค่โยน DataAccessException แทนที่จะเป็น ServiceException หรือไม่ ฉันแค่คิดว่าเลเยอร์การนำเสนอไม่ควรทราบเกี่ยวกับข้อยกเว้นการเข้าถึงข้อมูล แต่ฉันไม่เห็นจุดที่จับข้อยกเว้นที่ไม่สามารถกู้คืนได้เพื่อห่อไว้

23 design-patterns  exception-handling  spring  dao