เกิดข้อผิดพลาดในการยับยั้งการปฏิบัติที่ไม่ดีหรือไม่?

เกี่ยวกับคำถามดังนั้นผมถามนี่เกี่ยวกับรหัสบางอย่างผมก็ไม่แน่ใจเกี่ยวกับใครบางคนตอบว่า "BTW รหัสที่น่ากลัวนั่น. จะใช้ข้อผิดพลาดปราบปรามสัญลักษณ์ (@) เป็นจำนวนมาก"

มีเหตุผลหรือไม่ว่าทำไมนี่ถึงเป็นการปฏิบัติที่ไม่ดี? ด้วยสิ่งที่ชอบ:

$db=@new mysqli($db_info) or die('Database error');

มันช่วยให้ฉันแสดงข้อความข้อผิดพลาดที่กำหนดเอง โดยไม่มีการระงับข้อผิดพลาดจากนั้นจะยังคงแสดงข้อความ PHP ทั่วไปของ:

คำเตือน : mysqli :: mysqli (): php_network_getaddresses: getaddrinfo ล้มเหลว: ไม่รู้จักโฮสต์ดังกล่าว ในบาง \ file \ pathบนบรรทัด 6

เช่นเดียวกับ 'ข้อผิดพลาดฐานข้อมูล'

ข้อผิดพลาดในการระงับไม่ดีเสมอและถ้าเป็นเช่นนั้นสิ่งที่เฉพาะเจาะจงเกี่ยวกับข้างต้นจะไม่ดี?

อัปเดต: รหัสจริงที่ฉันใช้คือ:

or error('Datatabase error', 'An error occurred with the database' . (($debug_mode) ? '<br />MySQL reported: <b>' . $db->error . '</b><br />Error occurred on line <b>' . __LINE__ . '</b> of <b>' . __FILE__ . '</b>' : ''))

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

ฉันคิดว่าคุณกำลังทำสิ่งที่ถูกต้องโดยการระงับข้อผิดพลาดเพราะคุณกำลังดำเนินการจัดการข้อผิดพลาดของคุณเอง

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

try {
    db = new MySQLi(dbInfo);
} catch (SQLException connectionFailure) {
    die("Database error");
}

(ใน Java คุณไม่ต้องการให้ servlet engine ตาย แต่คุณเข้าใจแล้ว)

อย่างไรก็ตามสิ่งนี้ไม่เป็นที่ยอมรับ:

try {
    db = new MySQLi(dbInfo);
} catch (Exception e) {
}

การปราบปรามข้อผิดพลาด PHP ส่วนใหญ่จะทำอย่างไม่ระมัดระวังซึ่งคล้ายกับตัวอย่างหลังดังนั้นปฏิกิริยาตอบโต้การกระตุกเข่าของคุณกับรหัสของคุณ

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

ในตัวอย่างเฉพาะนี้“ ข้อผิดพลาดของฐานข้อมูล ” ไม่ใช่ข้อความแสดงข้อผิดพลาดที่ดีมาก มีบางอย่างผิดพลาดกับ DB ไม่สว่างมาก “ คำเตือน: mysqli :: mysqli (): php_network_getaddresses: getaddrinfo ล้มเหลว: ไม่รู้จักโฮสต์ดังกล่าว ในบาง \ file \ path บนบรรทัด 6 ” เป็นจริงข้อผิดพลาดที่ดีกว่า มันทำให้คุณมีสถานที่และสาเหตุของปัญหา คุณสามารถข้ามไปทางขวาและเริ่มการดีบั๊กได้เนื่องจากพบข้อผิดพลาดแล้ว

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

มีบางกรณีที่คุณรู้ว่าข้อผิดพลาดบางอย่างที่จะเปิดขึ้นว่าการแก้ไขปัญหาที่เกิดขึ้นจริงมีราคาแพงกว่าสมรข้อความ (และความทุกข์ทรมานผลกระทบที่อาจเกิดขึ้นจากการที่) และ นี่อาจเป็นกรณีในบทเดียว แต่การขยับนิ้วของคุณเข้าไปในหูและไปที่ " la la la " ไม่ใช่การตอบสนองอย่างมืออาชีพต่อข้อบกพร่อง (ที่มีศักยภาพ)

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

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

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

ใช่ข้อผิดพลาดในการปราบปรามผู้ประกอบการมักเป็นความคิดที่ไม่ดี

คุณควรจัดการการรายงานข้อผิดพลาดในการกำหนดค่า ( php.ini) ดังนั้นคุณสามารถเลือกการตั้งค่าที่แตกต่างกันสำหรับแต่ละสภาพแวดล้อม (เช่นปล่อยให้คำเตือนในการพัฒนาและซ่อนไว้ในการผลิต)

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

ฉันไม่สามารถคิดถึงการใช้งานอื่น ๆ