오류가 나쁜 연습을 억제하고 있습니까?

SO 질문에 대해 내가 확실하지 않은 코드에 대해 여기 에 물었 습니다 . 누군가가 "BTW, 끔찍한 코드 : 오류 억제 기호 (@)를 많이 사용합니다."라고 대답했습니다.

이것이 나쁜 습관 인 이유가 있습니까? 다음과 같은 것들로 :

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

사용자 지정 오류 메시지 만 표시 할 수 있습니다. 오류를 억제하지 않으면 다음과 같은 일반적인 PHP 메시지가 계속 표시됩니다.

경고 : mysqli :: mysqli () : php_network_getaddresses : getaddrinfo 실패 : 알려진 호스트가 없습니다. 에서 일부 \ 파일 \ 경로 에 라인 (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");
}

(자바에서는 서블릿 엔진이 죽기를 원하지 않지만 아이디어를 얻습니다.)

그러나 이는 허용되지 않습니다.

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

대부분의 PHP 오류 억제는 후자의 예제와 유사하게 부주의하게 수행되므로 코드에 대한 무자비한 반응입니다.

오류 억제 그것은 단지 당신이 이미 알고있는 정보를 숨기하지 않기 때문에 (나쁜 뭔가 잘못). 또한 모르는 디버깅 ( 무엇을 , 어디서 , 왜 )에 필수적인 정보를 숨길 수 있습니다 .

이 특정 예에서“ 데이터베이스 오류 ”는 좋은 오류 메시지가 아닙니다. DB에 문제가 있습니다. 매우 깨달음. “ 경고 : mysqli :: mysqli () : php_network_getaddresses : getaddrinfo 실패 : 해당 호스트가 없습니다. 6 행의 some \ file \ path에 ''실제로 더 나은 오류 메시지입니다. 문제의 위치와 이유를 제공합니다. 오류가 이미 있기 때문에 바로 뛰어 들어 디버깅을 시작할 수 있습니다.

물론, 도서관 설계자들은 때때로 관련이없는 많은 경고를 불러 일으키는 경향이 있습니다. PHP에 관심이없는 경고를 필터링 할 수있는 방법이 있는지 충분히 알지 못합니다. 백 줄짜리 stacktrace를 읽는 것이 그리 밝지 않다는 것을 알고 있습니다. 그러나 너무 많은 정보에 대한 올바른 응답은 정보의 양을 0 으로 줄이는 것이 아니라 어떤 단계에서 관련이없는 부분을 걸러내는 것입니다. @운영자는이 세분화 (그것의 모토가없는 전부 또는 아무것도 ), 따라서 효과적인 오류 관리를위한 적절한 도구가 아닙니다.

특정 오류 가 발생 하고 실제 문제를 해결하는 것이 메시지를 무음 처리하는 것보다 비용이 많이 드는 경우가 있습니다 (그러면 잠재적으로 빠질 수 있음). 이것은 일회성 스크립트의 경우 일 수 있지만 손가락을 귀에 대고 " la la la " 가는 것은 (잠재적) 버그에 대한 전문적인 반응 이 아닙니다 .

오류를 숨기는 것은 문제를 숨기고 있기 때문에 나쁘다. 우리가 알지도 못하고 재무, 건강 및 방어 분야에서 사용되는 응용 프로그램과 같은 일부 중요한 응용 프로그램에서 예상치 못한 동작이 발생할 수 있습니다.

코드에 처리되지 않은 예외가 있고 사용자에게 실제 오류 메시지를 표시하는 것은 좋지 않습니다. 오류 메시지는 일반적으로 코드에 대해 많은 정보를 표시하므로 악의적 인 사용자와 해커가 조작하는 데 도움이 될 수 있기 때문에 보안 문제가 발생할 수 있습니다 시스템.

따라서 모범 사례는 다른 수준에서 오류를 처리하는 것입니다. 예를 들어 최상위 수준에서는 실제 오류를 기록하고 사용자에게 간단하고 사용자 친화적 인 메시지를 표시하여 오류를 처리 할 수 ​​있습니다.

예, 오류 억제 연산자는 일반적으로 나쁜 생각입니다.

구성에서 오류보고를 관리해야합니다 ( php.ini). 따라서 각 환경에 대해 다른 설정을 선택할 수 있습니다 (예 : 개발시 경고를 남기고 프로덕션 환경에서 숨기려면).

사용할 때 유일한 상황 @은 다른 개발자를 위해 라이브러리를 개발할 때입니다. 자발적으로 경고를 생성하는 작업을 선택하고 라이브러리 사용자에게 의존하지 않는 경고로 귀찮게하지 않으려 @는 경우 해결책이 될 수 있습니다.

다른 용도로는 생각할 수 없습니다.