มีข้อยกเว้นแนวคิด OOP หรือไม่

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

ข้อยกเว้นไม่ใช่แนวคิดของ OOP

แต่พวกมันไม่ได้เกี่ยวข้องอย่างสมบูรณ์ทั้งในจุดเล็ก ๆ จุดเดียว

ดังที่คำตอบอื่น ๆ ได้แสดง: แนวคิดของข้อยกเว้นทำให้เป็นภาษาที่ไม่ใช่ OOP หลายภาษา ไม่มีสิ่งใดในแนวคิดที่ต้องการบางอย่างจาก OOP

แต่ถ้าไม่ใช่ภาษา OOP ทั้งหมดที่ใช้ OOP อย่างจริงจังต้องมีข้อยกเว้นเนื่องจากวิธีการจัดการข้อผิดพลาดอื่นล้มเหลว ณ จุดหนึ่ง: ตัวสร้าง

หนึ่งในประเด็นของ OOP คือวัตถุจะต้องห่อหุ้มและจัดการสถานะภายในของมันอย่างสมบูรณ์และสม่ำเสมอ นี่ก็หมายความว่าใน OOP บริสุทธิ์คุณต้องมีแนวคิดในการสร้างวัตถุใหม่ที่มีสถานะคงที่ "atomically" - ทุกอย่างตั้งแต่การจัดสรรหน่วยความจำ (ถ้าจำเป็น) ไปจนถึงการเริ่มต้นไปสู่สถานะที่มีความหมาย (เช่น zeroing ง่าย ๆ ทำได้ในนิพจน์เดียว ดังนั้นตัวสร้างจะต้อง:

Foo myFoo = Foo("foo", "bar", 42);

แต่นี่หมายความว่าตัวสร้างสามารถล้มเหลวได้เนื่องจากข้อผิดพลาดบางอย่าง วิธีการเผยแพร่ข้อมูลข้อผิดพลาดจากตัวสร้างโดยไม่มีข้อยกเว้น?

• ส่งคืนค่าหรือไม่ ล้มเหลวเนื่องจากในบางภาษาnewสามารถส่งคืนได้เท่านั้นnullแต่ไม่ใช่ข้อมูลที่มีความหมายใด ๆ ในภาษาอื่น (เช่น C ++) myFooไม่ใช่ตัวชี้ nullคุณไม่สามารถตรวจสอบกับ นอกจากนี้คุณไม่สามารถถามmyFooเกี่ยวกับข้อผิดพลาด - มันไม่ได้เริ่มต้นและดังนั้น "ไม่มีอยู่" ในการคิด OOP

• ตั้งค่าสถานะข้อผิดพลาดส่วนกลางหรือไม่ มากเกี่ยวกับสภาวะห่อหุ้มแล้วมีตัวแปรทั่วโลกไหม? ไปที่ h ... ;-)

• ส่วนผสม? ไม่มีทางดีกว่า

• ?

ดังนั้นข้อยกเว้นเป็นแนวคิดพื้นฐานมากกว่า OOP แต่ OOP สร้างขึ้นบนพวกเขาด้วยวิธีธรรมชาติ

มันเกี่ยวข้องกับ OOP เท่านั้นหรือไม่

ไม่ได้ข้อยกเว้นและ OOP ไม่เกี่ยวข้องกัน

การจัดการข้อยกเว้นเป็นกลไกในการจัดการข้อผิดพลาด ข้อยกเว้นได้รับการจัดการโดยการบันทึกสถานะของการดำเนินการปัจจุบันในสถานที่ที่กำหนดไว้ล่วงหน้าและสลับการดำเนินการไปยังรูทีนย่อยเฉพาะที่เรียกว่าตัวจัดการข้อยกเว้น

การเปรียบเทียบ C ( ไม่ใช่ภาษา OOP จริง ๆมีความเป็นไปได้ที่จะเลียนแบบข้อยกเว้นใน C ) และ C ++ (OOP รองรับข้อยกเว้น) ไม่มีอะไรป้องกันคณะกรรมการมาตรฐานของ C จากการเพิ่มข้อยกเว้นในการจัดการ C มันจะยังไม่ทำให้ C เป็นภาษา OOP

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

ภาษาเชิงวัตถุมักจะมีคลาสข้อยกเว้นเนทิฟและขึ้นอยู่กับบริบทคำว่า "ข้อยกเว้น" อาจอ้างถึงคลาสเนเชอรัลนั้นแทนแนวคิดทั่วไป การจัดการข้อยกเว้นเชิงวัตถุคือส่วนใหญ่ของการวางวัตถุน้ำตาล syntactic และสามารถเลียนแบบได้อย่างง่ายดายในภาษาที่ไม่ใช่เชิงวัตถุอย่างเด็ดขาด นี่คือตัวอย่าง C จากwikibook การเขียนโปรแกรม C :

#include <stdio.h>
#include <setjmp.h>

jmp_buf test1;

void tryjump()
{
    longjmp(test1, 3);
}

int main (void)
{
    if (setjmp(test1)==0) {
        printf ("setjmp() returned 0.");
        tryjump();
    } else {
        printf ("setjmp returned from a longjmp function call.");
    }
}

คำตอบคือไม่ง่าย

ตัวอย่างที่ดีสำหรับภาษาที่ไม่ใช่ OO ที่มีข้อยกเว้นคือ ADA

คำตอบที่ดีมากอยู่ที่นี่แล้ว ตัวอย่างอื่น ๆ สำหรับภาษาการเขียนโปรแกรมที่ไม่ใช่ OOP ที่มีข้อยกเว้น:

• Oracle PL / SQL

• คลาสสิค Visual Basic (V6 และต่ำกว่า "On Error Goto" เป็นรูปแบบการจัดการข้อยกเว้น IMHO)

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

แนวคิดพื้นฐานที่อยู่เบื้องหลังข้อยกเว้นคือการล้างการไหลของโปรแกรมเพื่อให้โปรแกรมเมอร์สามารถติดตามเส้นทางการดำเนินการ "ปกติ" ได้ง่ายขึ้น พิจารณากรณีง่าย ๆ ในการเปิดไฟล์ใน C. ทันทีหลังจากพยายามเปิดไฟล์โปรแกรมเมอร์จำเป็นต้องตรวจสอบการตอบสนองจากการเรียก fopen () และตัดสินใจว่าการโทรสำเร็จหรือไม่ หากการโทรไม่สำเร็จโปรแกรมเมอร์จะต้องตอบสนองอย่างเหมาะสม การเรียกครั้งต่อไปในพา ธ การเรียกใช้งาน "ปกติ" อาจเป็นการเรียกไปยัง fread () หรือ fwrite () ซึ่งจะปรากฏขึ้นหลังจากจัดการกับข้อผิดพลาดหรือความล้มเหลว นั่นอาจเป็นในหน้าจอถัดไป

ด้วยภาษาที่มีข้อยกเว้นการโทร fopen () ที่เทียบเท่าสามารถติดตามได้ทันทีโดย fread () หรือ fwrite () ไม่มีการจัดการข้อผิดพลาดที่ซ่อน "ขั้นตอนถัดไป" ของเส้นทางการดำเนินการ "ปกติ" โปรแกรมเมอร์สามารถเห็นเส้นทางปกติมากขึ้นในหน้าจอเดียวและสามารถติดตามการดำเนินการได้ง่ายขึ้น การจัดการข้อผิดพลาดถูกย้ายไปยังส่วนอื่นของโปรแกรม

การยกเว้นตัวเองไม่ใช่แนวคิดของ OOP แต่มักจะนำไปใช้โดยใช้แนวคิดของ OOP ซึ่งทำให้สะดวกและมีประสิทธิภาพมากขึ้น ตัวอย่างเช่นข้อยกเว้นอาจถูกกำหนดด้วยลำดับชั้นการสืบทอด การใช้ตัวอย่างการเปิดและการอ่านหรือเขียนไฟล์ของเราการเรียกแต่ละครั้งนั้นอาจสร้างข้อยกเว้นที่หลากหลาย - FileClosedException, DeviceFullException, NoSuchFileException, InsufficientFilePermissionsException ฯลฯ แต่ละสายนั้นอาจสืบทอดมาจาก IOException สืบทอดจาก GenericException

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

บางคนก็ตอบว่า "ไม่" อย่างถูกต้องพร้อมตัวอย่างภาษา ฉันคิดว่าฉันสามารถขยายได้โดยการเพิ่มตัวอย่างเกี่ยวกับวิธีเพิ่มข้อยกเว้นให้กับภาษาโดยไม่เกี่ยวข้องกับ OOP

ฉันจะทำสิ่งนี้ในกรณีของ DSKL (Declarative Sequential Kernel Language) ของOZซึ่งเป็นภาษาที่เหมาะสำหรับสถาบันการศึกษาเช่นนี้ DSKL (หรือ DKL) สามารถดูได้ที่นี่ (ผลการค้นหาแบบสุ่ม) ส่วน Statement และ Values คำจำกัดความที่แน่นอนนั้นไม่สำคัญนอกเหนือจากนี้เป็นภาษาที่ง่ายมากโดยไม่มีตัวแปรที่แก้ไขได้ (จะถูกประกาศและผูกไว้ภายหลัง) และไม่มีการสร้าง OOP

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

หากเราเพิ่มข้อยกเว้นในภาษาเคอร์เนลเราจะมีภาษาที่ไม่มีการสนับสนุน OOP แต่มีข้อยกเว้น ให้ฉันแสดงวิธี:

การนิยามเครื่องนามธรรมด้วยสแต็กและที่เก็บข้อมูลเราสามารถกำหนดสิ่งที่แต่ละคำสั่งในภาษาของเราควรทำ ( ความหมายของคำสั่ง) ตัวอย่างเช่นskipในสแต็กไม่ควรทำอะไรเลยA = 3ในสแต็กควรผูก (/ รวม) A ถึง (/ ด้วย) 3

เราเริ่มต้นด้วยการเพิ่มไวยากรณ์ของการกำหนดข้อยกเว้นของเรา เราทำสิ่งนี้โดยการเพิ่มอนุประโยคอีกสองข้อลง<statement>ใน DKL

<statement>  ::== ... (old stuff)
                 | try <statement> catch <id> then <statement> end
                 | raise <id> end

นี่คือการลอง / จับที่รู้จักและวิธีการยก / โยนข้อยกเว้น

เรากำหนดความหมายของพวกเขาโดยวิธีที่พวกเขาควรทำงานบนเครื่องนามธรรม:

ลองใช้
คำสั่ง semantic คือ: (try <statement1> catch <id> then <statement2> end)
Do:

1. กดลงบนสแต็กคำสั่ง semantic (catch <id> then <statement2> end)
2. กดลงบนสแต็กคำสั่ง semantic (<statement1>)

โปรดทราบว่าคำสั่ง 1 จะอยู่ด้านบนสุดของสแต็กและลองดำเนินการก่อน

เพิ่ม
คำสั่งทางความหมายคือ: (raise <id> end)
ทำ:

1. หากไม่มีอะไรเพิ่มเติมอยู่ในสแต็กให้หยุดและรายงานข้อยกเว้นที่ไม่ได้ตรวจสอบ
2. มิฉะนั้นให้เปิดข้อความสั่งความหมายแรกจากสแต็ก ถ้าไม่ใช่คำสั่ง catch ให้ไปที่ขั้นตอนที่ 1
3. เราได้รับการจับบนแบบฟอร์ม(catch <id> then <statement> end)
   กด(<statement>)ลงบนกองซ้อน

Catch
ถ้าเราเห็นคำสั่ง catch ในระหว่างการดำเนินการตามปกติหมายความว่าสิ่งใดก็ตามที่ถูกดำเนินการภายในโดยไม่มีการยกระดับขึ้นไปยกเว้นระดับนี้ ดังนั้นเราแค่ป๊อปอัพcatchสแต็คและไม่ทำอะไรเลย

QED เรามีภาษาที่มีข้อยกเว้นและไม่มีความเป็นไปได้ของ OOP

_{ฉันได้ลบส่วนของสภาพแวดล้อมออกจากเครื่องนามธรรมเพื่อให้ง่ายขึ้น}

เลขที่

IIRC มีข้อยกเว้นปรากฏขึ้นก่อนภาษา OO แรก AFAIK ข้อยกเว้นได้รับการสนับสนุนเป็นครั้งแรกโดยการนำ LISP ไปใช้ก่อน ภาษาที่มีโครงสร้างต้น (เช่น ALGOL) และภาษา OO ตอนต้น (เช่น SIMULA) ไม่สนับสนุนข้อยกเว้น