เหตุใดการขอให้อภัยจึงง่ายกว่าการขออนุญาตใน Python

LBYL ซึ่งเป็นแนวทางตอบโต้กับ EAFP ไม่มีส่วนเกี่ยวข้องกับการยืนยัน เพียงหมายความว่าคุณต้องเพิ่มเครื่องหมายถูกก่อนที่จะลอง เพื่อเข้าถึงบางสิ่งที่อาจไม่มีอยู่ที่นั่น

เหตุผลที่ Python เป็น EAFP นั้นต่างจากภาษาอื่นๆ (เช่น Java) - ใน Python การจับข้อยกเว้นนั้นมีราคาไม่แพงนัก และนั่นคือเหตุผลว่าทำไมคุณถึงได้รับการสนับสนุนให้ใช้มัน

ตัวอย่างสำหรับ EAFP:

try:
    snake = zoo['snake']
except KeyError as e:
    print "There's no snake in the zoo"
    snake = None

ตัวอย่างสำหรับ LBYL:

if 'snake' in zoo:
    snake = zoo['snake']
else:
    snake = None

คุณกำลังผสมสองสิ่งที่นี่: การยืนยันและตรรกะที่ใช้ EAFP

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

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

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

# LBYL
if key in dic:
    print(dic[key])
else:
    handleError()

# EAFP
try:
    print(dic[key])
except KeyError:
    handleError()

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

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

คำถามที่ดี! มีคำถามน้อยมากใน StackOverflow ที่ถามเกี่ยวกับ "ปรัชญาเบื้องหลังหลักการ"

เกี่ยวกับ คำจำกัดความ EAFP ในอภิธานศัพท์ Python ฉันจะไปมากกว่านี้อีก และกล่าวว่าการกล่าวถึง "ข้อยกเว้นแคชหากสมมติฐานพิสูจน์ได้ว่าเท็จ" ค่อนข้างทำให้เข้าใจผิดในบริบทนี้ เพราะมาเผชิญหน้ากัน ข้อมูลโค้ดที่ 2 ต่อไปนี้ไม่ได้ดู "สะอาดและรวดเร็ว" มากขึ้น (คำที่ใช้ในคำจำกัดความข้างต้น) ไม่น่าแปลกใจที่ OP จะถามคำถามนี้

# LBYL
if key in dic:
    print(dic[key])
else:
    handleError()

# EAFP
try:
    print(dic[key])
except KeyError:
    handleError()

ฉันจะบอกว่าช่วงเวลาที่แท้จริงที่ EAFP โดดเด่นก็คือคุณไม่ได้เขียน try ... except ... เลย อย่างน้อยก็ไม่ใช่ในฐานโค้ดพื้นฐานส่วนใหญ่ของคุณ เพราะ กฎข้อแรกของการจัดการข้อยกเว้น: อย่าทำ การจัดการข้อยกเว้น ด้วยเหตุนี้ เรามาเขียนตัวอย่างที่ 2 ใหม่กัน:

# Real EAFP
print(dic[key])

ตอนนี้แนวทาง EAFP ที่แท้จริงนั้นไม่สะอาดและรวดเร็วใช่ไหม

ฉันจะขยายคำตอบจาก @RayLuo

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

# LBYL
if key in dic:
    # RACE CONDITION
    print(dic[key])
else:
    handleError()

# EAFP
try:
    print(dic[key])
except KeyError:
    handleError()

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

นั่นหมายถึงวิธีที่ถูกต้องในการใช้ LBYL คือ:

if key in dic:
    try:
        print(dic[key])
    except KeyError:
        handleError()
else:
    handleError()

โปรดทราบว่าส่วนคำสั่ง try / except นั้นเหมือนกับวิธี EAFP ทุกประการ

เนื่องจากคุณต้องจัดการข้อยกเว้นในลักษณะ EAFP แม้ว่าจะใช้วิธีการ LBYL คุณจึงอาจใช้แนวทาง EAFP ในตอนแรกได้เช่นกัน

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

บรรทัดล่าง: LBYL ไม่ทำงานในกรณีทั่วไป แต่ EAFP ใช้งานได้ นักพัฒนาที่ดีมุ่งเน้นไปที่รูปแบบการแก้ปัญหาทั่วไปที่พวกเขาสามารถใช้ได้อย่างมั่นใจกับปัญหาต่างๆ มากมาย เรียนรู้การใช้ EAFP อย่างสม่ำเสมอ