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

พวกเขาทั้งคู่มีControllers ที่ตัดสินใจว่าจะไปที่ไหนต่อไปและให้ข้อมูลกับตรรกะปลายทาง การกระทำของผู้ใช้จากโดเมนของโทรศัพท์เก่าโรงเรียนเช่นโทน DTMF กลายเป็นพารามิเตอร์กับวิธีการดำเนินการ แต่แทนที่จะกลับสิ่งที่ต้องการพวกเขาโยนViewResultStateTransitionException

ฉันคิดว่าความแตกต่างที่สำคัญคือวิธีการดำเนินการเป็นvoidหน้าที่ ผมจำไม่ได้ทุกสิ่งที่ฉันทำกับความเป็นจริงนี้ แต่ผมเคยลังเลที่จะได้ไปลงที่ถนนในการจดจำมากเพราะตั้งแต่งานที่เหมือน 15 ปีที่ผ่านมาผมไม่เคยเห็นนี้ในรหัสการผลิตที่งานอื่น ๆ ฉันสันนิษฐานว่านี่เป็นสัญญาณว่าเป็นรูปแบบการต่อต้านที่เรียกว่า

เป็นกรณีนี้หรือไม่และถ้าเป็นเช่นนั้นทำไม

อัปเดต: เมื่อฉันถามคำถามฉันมีคำตอบในใจของ @ MasonWheeler ดังนั้นฉันจึงไปพร้อมกับคำตอบที่เพิ่มความรู้ให้มากที่สุด ฉันคิดว่าเขาเป็นคำตอบที่ดีเช่นกัน

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

สรุปโดยย่อเกี่ยวกับสาเหตุโดยทั่วไปเป็นรูปแบบการต่อต้าน:

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

อ่านการสนทนาที่ wiki ของ Ward เพื่อดูข้อมูลเชิงลึกเพิ่มเติม

ดูซ้ำซ้อนของคำถามนี้ที่นี่

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

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

หากคุณไม่ได้ใช้การยกเว้นด้วยเหตุผลข้อใดข้อหนึ่งต่อไปนี้อาจเป็นวิธีที่ดีกว่า

GOTOจะมีการยกเว้นเป็นพลังเป็นตและ พวกเขาเป็นโครงสร้างการไหลของการควบคุมสากล

ในบางภาษาพวกเขาเป็นโครงสร้างการควบคุมการไหลที่เป็นสากลเท่านั้น ตัวอย่างเช่น JavaScript ไม่มีการต่อเนื่องและGOTOไม่มีการโทรหางที่เหมาะสม ดังนั้นหากคุณต้องการใช้โฟลว์ควบคุมขั้นสูงใน JavaScript คุณต้องใช้ข้อยกเว้น

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

คุณพูดถึงเครื่องจักรของรัฐ SM นั้นเป็นเรื่องเล็กน้อยที่จะนำไปใช้กับการโทรที่เหมาะสม: ทุกรัฐเป็นรูทีนย่อยทุกการเปลี่ยนสถานะคือการเรียกรูทีนย่อย SM สามารถนำไปใช้กับGOTOหรือ Coroutines หรือ Continuations ได้อย่างง่ายดาย อย่างไรก็ตาม Java ไม่ได้มีของบรรดาสี่ แต่มันก็ไม่ได้มีข้อยกเว้น ดังนั้นจึงเป็นที่ยอมรับอย่างสมบูรณ์ในการใช้สิ่งเหล่านี้เป็นโฟลว์ควบคุม (อันที่จริงตัวเลือกที่ถูกต้องน่าจะเป็นภาษาที่มีโครงสร้างการควบคุมการไหลที่เหมาะสม แต่บางครั้งคุณอาจติดกับ Java)

ตามที่คนอื่น ๆ ได้กล่าวไว้เป็นจำนวนมาก ( เช่นในคำถาม Stack Overflow ) หลักการของความประหลาดใจอย่างน้อยจะไม่อนุญาตให้คุณใช้ข้อยกเว้นมากเกินไปสำหรับจุดประสงค์การควบคุมการไหลเท่านั้น ในทางกลับกันไม่มีกฎใดถูกต้อง 100% และมีกรณีเหล่านั้นเสมอที่ข้อยกเว้นคือ "เครื่องมือที่เหมาะสม" - เหมือนgotoตัวของมันเองโดยวิธีการที่จัดส่งในรูปแบบbreakและcontinueในภาษาเช่น Java ซึ่ง มักเป็นวิธีที่สมบูรณ์แบบในการกระโดดออกจากลูปซ้อนกันอย่างหนักซึ่งไม่สามารถหลีกเลี่ยงได้เสมอ

โพสต์บล็อกต่อไปนี้อธิบายกรณีการใช้งานที่ค่อนข้างซับซ้อน แต่ก็ค่อนข้างน่าสนใจสำหรับผู้ที่ไม่ใช่คนท้องถิ่น ControlFlowException :

• http://blog.jooq.org/2013/04/28/rare-uses-of-a-controlflowexception

มันอธิบายวิธีที่อยู่ภายในของjOOQ (ไลบรารีนามธรรมของ SQL สำหรับ Java) (ข้อจำกัดความรับผิดชอบ: ฉันทำงานกับผู้ขาย), ข้อยกเว้นดังกล่าวจะถูกใช้เป็นครั้งคราวเพื่อยกเลิกกระบวนการเรนเดอร์ SQL ก่อนเมื่อเงื่อนไขบางอย่าง "หายาก"

ตัวอย่างของเงื่อนไขดังกล่าวคือ:

• พบค่าการผูกมากเกินไป ฐานข้อมูลบางตัวไม่สนับสนุนจำนวนการผูกค่าในงบ SQL ของตนเอง (SQLite: 999, 10.1.1: 1024, Sybase ASE 15.5: 2000, SQL Server 2008: 2100) ในกรณีดังกล่าว jOOQ จะยกเลิกเฟสการเรนเดอร์ SQL และแสดงคำสั่ง SQL อีกครั้งด้วยค่าการโยงแบบอินไลน์ ตัวอย่าง:

  // Pseudo-code attaching a "handler" that will
  // abort query rendering once the maximum number
  // of bind values was exceeded:
  context.attachBindValueCounter();
  String sql;
  try {
  
    // In most cases, this will succeed:
    sql = query.render();
  }
  catch (ReRenderWithInlinedVariables e) {
    sql = query.renderWithInlinedBindValues();
  }

  หากเราแยกค่าการเชื่อมโยงออกจากแบบสอบถาม AST อย่างชัดเจนเพื่อนับพวกเขาทุกครั้งเราจะสูญเสียรอบการทำงานของ CPU ที่มีค่าสำหรับ 99.9% ของการสืบค้นที่ไม่ประสบปัญหานี้

• ตรรกะบางอย่างใช้ได้เฉพาะทางอ้อมผ่าน API ที่เราต้องการดำเนินการ "บางส่วน" เท่านั้น UpdatableRecord.store()วิธีการสร้างINSERTหรือUPDATEคำสั่งขึ้นอยู่กับRecord's ธงภายใน จาก "ข้างนอก" เราไม่ทราบว่ามีตรรกะประเภทใดstore()(เช่นการล็อกในแง่ดีการจัดการฟังเหตุการณ์ ฯลฯ ) ดังนั้นเราจึงไม่ต้องการทำซ้ำตรรกะนั้นเมื่อเราเก็บบันทึกหลายชุดในชุดคำสั่ง โดยที่เราต้องการstore()สร้างคำสั่ง SQL เพียงอย่างเดียวไม่ใช่เรียกใช้งานจริง ตัวอย่าง:

  // Pseudo-code attaching a "handler" that will
  // prevent query execution and throw exceptions
  // instead:
  context.attachQueryCollector();
  
  // Collect the SQL for every store operation
  for (int i = 0; i < records.length; i++) {
    try {
      records[i].store();
    }
  
    // The attached handler will result in this
    // exception being thrown rather than actually
    // storing records to the database
    catch (QueryCollectorException e) {
  
      // The exception is thrown after the rendered
      // SQL statement is available
      queries.add(e.query());                
    }
  }

  หากเรามีstore()ตรรกะภายนอกในAPI "ที่ใช้ซ้ำได้" ซึ่งสามารถปรับแต่งให้เป็นทางเลือกที่ไม่ได้เรียกใช้งาน SQL เราจะมองหาการสร้าง API ที่ค่อนข้างยากที่จะรักษาและไม่สามารถใช้งานได้อีก

ข้อสรุป

ในสาระสำคัญการใช้งานของเราที่ไม่ใช่ในท้องถิ่นเหล่านี้gotoเป็นไปตามสิ่งที่Mason Wheelerกล่าวในคำตอบของเขา:

"ฉันเพิ่งเจอสถานการณ์ที่ฉันไม่สามารถจัดการกับมันได้อย่างถูกต้อง ณ จุดนี้เพราะฉันมีบริบทไม่เพียงพอที่จะจัดการกับมัน แต่กิจวัตรที่เรียกฉัน ."

การใช้งานทั้งสองแบบControlFlowExceptionsนั้นค่อนข้างง่ายต่อการใช้งานเมื่อเทียบกับทางเลือกของพวกเขาทำให้เราสามารถใช้ตรรกะที่หลากหลายได้

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

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

มันได้รับการกล่าวพันครั้งว่าข้อยกเว้นมีความหมายสำหรับเงื่อนไขพิเศษ การเชื่อมต่อฐานข้อมูลที่ใช้งานไม่ได้เป็นเงื่อนไขที่ยอดเยี่ยม ผู้ใช้ป้อนตัวอักษรในช่องใส่ที่ควรอนุญาตให้เฉพาะตัวเลขไม่ได้

ข้อผิดพลาดในซอฟต์แวร์ของคุณที่ทำให้ฟังก์ชั่นถูกเรียกใช้โดยมีข้อโต้แย้งที่ผิดกฎหมายเช่นnullที่ไม่อนุญาตเป็นเงื่อนไขพิเศษ

ด้วยการใช้ข้อยกเว้นสำหรับบางสิ่งที่ไม่เป็นพิเศษคุณกำลังใช้ abstractions ที่ไม่เหมาะสมสำหรับปัญหาที่คุณพยายามแก้ไข

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

แต่ภาษาอื่นเช่นทับทิมมีไวยากรณ์คล้ายข้อยกเว้นสำหรับโฟลว์การควบคุม สถานการณ์พิเศษได้รับการจัดการโดยraise/ rescueโอเปอเรเตอร์ แต่คุณสามารถใช้throw/ catchสำหรับการสร้างโฟลว์การควบคุมที่เหมือนข้อยกเว้น **

ดังนั้นแม้จะมีข้อยกเว้นทั่วไปไม่ได้ใช้สำหรับการควบคุมการไหล, ภาษาของคุณเลือกอาจมีสำนวนอื่น ๆ

* ตัวอย่างของการใช้งานข้อยกเว้นมีค่าใช้จ่ายสูง: ฉันเคยถูกตั้งค่าให้ปรับใช้แอปพลิเคชัน ASP.NET Web Form ที่มีประสิทธิภาพต่ำ มันกลับกลายเป็นว่าการแสดงผลของตารางที่มีขนาดใหญ่ได้รับการเรียกร้องint.Parse()ในการประมาณ สตริงว่างหนึ่งพันรายการบนหน้าเฉลี่ย มีข้อยกเว้นนับพันที่จัดการ โดยการแทนที่รหัสด้วยint.TryParse()ฉันโกนออกหนึ่งวินาที! สำหรับทุก ๆ หน้าขอ!

** สิ่งนี้อาจสร้างความสับสนอย่างมากสำหรับโปรแกรมเมอร์ที่มาจาก Ruby ในภาษาอื่น ๆ เนื่องจากทั้งคู่throwและcatchเป็นคำหลักที่เกี่ยวข้องกับข้อยกเว้นในภาษาอื่น ๆ อีกมากมาย

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

status = getValue(&inout);
if (status < 0)
{
    logError("message");
    return status;
}

doSomething(*inout);

หรือเทียบเท่าในภาษาของคุณเช่นส่งคืน tuple โดยมีค่าเดียวเป็นสถานะข้อผิดพลาด ฯลฯ บ่อยครั้งที่คนที่ชี้ให้เห็นว่าการจัดการข้อยกเว้น "แพง" เป็นอย่างไรให้ละเลยifงบพิเศษทั้งหมดข้างต้นที่คุณต้องเพิ่มหากคุณไม่ได้ t ใช้ข้อยกเว้น

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

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

ใน Python มีการใช้ข้อยกเว้นสำหรับตัวสร้างและการยกเลิกซ้ำ Python มีลอง / ยกเว้นบล็อกที่มีประสิทธิภาพมาก แต่จริงๆแล้วการเพิ่มข้อยกเว้นมีค่าใช้จ่ายบางอย่าง

เนื่องจากขาดการแบ่งหลายระดับหรือคำสั่ง goto ใน Python ฉันมีบางครั้งใช้ข้อยกเว้น:

class GOTO(Exception):
  pass

try:
  # Do lots of stuff
  # in here with multiple exit points
  # each exit point does a "raise GOTO()"
except GOTO:
  pass
except Exception as e:
  #display error

มาร่างภาพการใช้งานข้อยกเว้น:

อัลกอริทึมค้นหาซ้ำจนกระทั่งพบบางสิ่งบางอย่าง ดังนั้นการย้อนกลับมาจากการสอบถามซ้ำจะต้องตรวจสอบผลการค้นหาและกลับมาแล้วดำเนินการต่อ และนั่นกลับมาซ้ำ ๆ จากความลึกของการเรียกซ้ำ

นอกจากนี้ต้องใช้บูลีนพิเศษfound(เพื่อบรรจุในชั้นเรียนมิฉะนั้นอาจจะมีเพียง int เท่านั้นที่ถูกส่งคืน) และสำหรับความลึกในการเรียกซ้ำจะมี postlude เดียวกันเกิดขึ้น

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

การเขียนโปรแกรมเป็นเรื่องเกี่ยวกับงาน

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

ทุกครั้งที่มีการเรียกเมธอดผู้เรียกจะพูดว่า"ฉันไม่รู้วิธีทำงานนี้ แต่คุณรู้วิธีคุณจึงทำเพื่อฉัน"

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

วิธีการเริ่มต้นในการสื่อสารนี้คือการคืนค่า "ขยะ" เพียง บางทีคุณอาจคาดหวังว่าจำนวนเต็มบวกดังนั้นเมธอดที่เรียกคืนค่าจำนวนลบ อีกวิธีหนึ่งในการบรรลุเป้าหมายนี้คือการตั้งค่าความผิดพลาดที่ใดที่หนึ่ง แต่น่าเสียดายที่ทั้งสองวิธีมีผลในต้นแบบให้ฉันตรวจสอบ-over-ที่นี่เพื่อทำให้แน่ใจว่า everything's เพียวรหัส เมื่อสิ่งต่าง ๆ ซับซ้อนมากขึ้นระบบนี้ก็จะแยกจากกัน

การเปรียบเทียบที่ยอดเยี่ยม

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

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

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

Heck, คุณอาจไม่ได้รู้ว่าคุณต้องเป็นช่างไฟฟ้าที่คุณอาจไม่ทราบว่าที่คุณต้องการ คุณเป็นแค่ผู้บริหารระดับกลางในธุรกิจซ่อมแซมบ้านและคุณให้ความสำคัญกับระบบประปา ดังนั้นคุณบอกว่าคุณเป็นหัวหน้าเกี่ยวกับปัญหาและจากนั้นเขาบอกช่างไฟฟ้าให้แก้ไข

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

ดังนั้น ... การต่อต้านแบบ?

ตกลงดังนั้นการทำความเข้าใจจุดยกเว้นเป็นขั้นตอนแรก ต่อไปคือการเข้าใจสิ่งที่ต่อต้านรูปแบบคือ

จึงจะมีคุณสมบัติเป็นรูปแบบการต่อต้านมันต้อง

• แก้ปัญหา
• มีผลกระทบเชิงลบอย่างชัดเจน

จุดแรกพบได้ง่าย - ระบบใช้งานใช่ไหม

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

แต่ที่ไม่ชัดเจนอันตราย มันเป็นวิธีที่ไม่ดีที่จะทำสิ่งต่าง ๆ และแปลก แต่มีรูปแบบต่อต้าน? เลขที่ ... แปลก