在PHP網站上處理錯誤

有人可以指導我如何實現正確的方向，並在什麼階段添加錯誤處理代碼？在PHP網站上處理錯誤

網站：
像linkedin這樣的社交網絡。平臺是MySql和codeignitor PHP。要求：3例出錯：

前端像http代碼。在這種情況下，用戶被重定向到一個std消息頁面。數據庫無法捕獲。
第二種情況是後端錯誤，如服務器需時過長，寫入數據庫時出錯，其他數據庫問題，代碼爆炸等。預期用戶在所有這些情況下只會看到一個錯誤消息框，表示「某人已通知，稍後再試「。類似於它在Facebook上的外觀，除了Facebook根據錯誤類型具有不同的錯誤文本。
第三種錯誤類型是與會話相關的：會話期間發生中斷的cookies和發生超時的cookie，在這種情況下會顯示請求登錄消息窗口。

我的問題是現在：

爲了捕捉下降的情況下2內的所有各種錯誤，可以在同時開發過程中完成或做開發者必須回去並在代碼中的每個入口點添加項目結束處的錯誤捕獲，這可能是數百萬行代碼？
我的團隊告訴我他們不知道在整個開發完成之前情況2中可能發生錯誤的所有可能情況。但是我認爲無論發生什麼，錯誤的代碼都是一般的。除代碼外，還有一個錯誤捕獲子句，用於捕獲我們想要捕獲的錯誤類別以及錯誤消息，如果不同，可以隨時添加，但底層錯誤代碼相同，因此甚至可以在開發之前寫入錯誤代碼。
如何找到所有可能的情況或捕獲所有可能的情況在情況2中可能會出現錯誤，其中可能有數百個用於任何級別或DB讀取/寫入錯誤的事物的使用情況等等。需要單獨的代碼或每個共同代碼捕捉所有？

我的開發人員也是新的，所以我不認爲任何人都確切知道何時以及如何處理網站上的錯誤處理。在系統的後端時，出現錯誤的郵件將被髮送到管理員，我建立一個錯誤跟蹤系統，這樣我們就可以在後臺自動與狀態，類型，票據keeptrack的問題等

2010-12-19 Mani

您希望將多少信息返回給用戶？如果發生數據庫讀/寫錯誤，是否希望告訴他們？我認爲大多數情況下都應該使用通用錯誤，然後將錯誤（取決於開發人員的偏好程度）記錄到文件中（如果文件系統出現故障，可能會影響數據庫以及如果它在同一臺服務器上）。計劃任務然後可以定期向負責人發送電子郵件並清除/存檔此文件。 – stealthyninja 2010-12-19 03:47:19

從用戶的角度來看，應該只能看到兩種類型的錯誤：404和503.就這樣。只要你遵循這個規則，所有內在的本質並不重要 – 2010-12-19 03:58:58

對於＃1 - 是的。 set_error_handler +異常將允許您捕獲發生的任何錯誤。對於＃2 - 爲什麼他們需要知道所有錯誤類型？即使完成，他們也不會知道它。這是無稽之談。舉例來說，一些圖像處理庫在更新之後會變得瘋狂。沒有必要知道所有可能的錯誤。有必要*捕捉所有可能的錯誤。 – 2010-12-19 04:12:41

1 。要捕獲情況2中的所有各種錯誤，是否可以在開發進行的同時完成，或者開發人員必須返回並在項目結束時在每個入口點處添加錯誤捕獲代碼是數百萬行代碼？

這兩者，但通常只是在開發正在進行時才需要。考慮每行代碼可以自行生成哪些類型的錯誤（尤其是從外部或數據庫獲取數據時）是非常重要的，因此您需要考慮每個步驟中的所有錯誤。爲了幫助插入特殊情況處理後一切已經到位，這是一個主人error handling函數發揮作用。只要注意哪些錯誤級別永遠不會觸發您的自定義錯誤處理。您可能還對Exception class感興趣。同樣，爲了更容易地插入特殊情況處理，只需在更少的點上進行更新，就可以將Exception類擴展爲您自己的特殊錯誤對象。

2.我的團隊告訴我，他們不知道在案例2中發生錯誤的所有可能情況，直到整個開發完成。但是我認爲無論發生什麼，錯誤的代碼都是一般的。除代碼外，還有一個錯誤捕獲子句，用於捕獲我們想要捕獲的錯誤類別以及錯誤消息，如果不同，可以隨時添加，但底層錯誤代碼相同，因此甚至可以在開發之前寫入錯誤代碼。

種類與＃1相同的問題。恕我直言，你是對的。在某些情況下，他們也是如此。一位開發人員真的無法知道另一個開發人員的代碼會產生什麼類型的錯誤，直到他們看到代碼或獲得最終文檔。

3.How做我找出所有可能的或用於捕獲所有可能的情況下，可能會發生的情況下，2，可以有幾百個在任何級別或DB吹起來的東西usecases的讀/寫錯誤，等錯誤我們是否需要單獨的代碼來捕獲每個或一個共同的代碼？

同樣會關閉的問題＃1，使用自定義錯誤處理功能或關閉擴展Exception類（甚至做獨立的類來處理DB嘗試/捕獲VS文件訪問嘗試/捕獲等），這應該顯著幫助。假設您發現數據庫可能吐出的新錯誤。如果已將try和catch塊中的連接和查詢函數包裝在一起，則只需在擴展的Exception類中添加處理腳本，而不是在DB功能所在的位置添加處理腳本。例如，你可以選擇爲所有的db連接做這樣的事情。 DB_Exception在這種情況下是你的Exception擴展版本，它本身可以做自己的任何數量的故障排除任務：

function db_connect() { 
    $MySQLi = new mysqli(DB_HOST, DB_USERNAME, DB_PW, DB_NAME, DB_PORT, DB_SOCKET); 
    if ($MySQLi->connect_error) throw new DB_Exception($MySQLi->connect_error); 
    if ($MySQLi->error) throw new DB_Exception($MySQLi->error); 
    return $MySQLi; 
    } 

try {$MySQLi = db_connect();} 
catch (DB_Exception $e) {if (!$e->is_fixed_now) die($e->special_message);}

你也可以有你的擴展Exception類引用一組由$code結構列舉罐頭回應論據。但是，你真的應該而不是嘗試應用特殊的錯誤處理，你可能會得到每一個可能的數據庫錯誤。在大多數情況下，只要獲取MySQL錯誤文本，無論它可能是什麼，並將其轉發給管理員，它的效率和方式都要低得多。

對於您向用戶展示的文字，最好始終保持簡潔和翔實，同時絕對不要遺漏您網站的內部運作。例如：您的數據庫服務器崩潰或有人錯誤地設置了文件權限錯誤：您應該告訴用戶「對不起，技術上的困難，此特定內容不可用，我們的工作人員已收到通知，請稍後再試。 @ so.com或致電555-1212。「您也可以使用基於Exception$code參數的罐裝消息，與上面相同，但不會提供任何有助於發生站點攻擊的信息。

此外，「在發生錯誤時系統的後端將發送電子郵件給管理員」並不是一個好主意。用戶可能會一直坐在那裏刷新，直到它神奇地再次開始工作。你可能很容易陷入電子郵件風暴。一種可能的解決方案是運行10分鐘的cron作業檢查以查看錯誤日誌在過去10分鐘內是否已被修改，並通過電子郵件發送新日誌條目摘要。或者，如果您有問題故障單系統，只有在該主題上打開的故障單不存在時才能打開錯誤腳本。

來源

2010-12-19 05:15:05

應該爲您希望生成的HTTP錯誤提供適當的錯誤頁面。這些頁面應該提供有關錯誤的最少數據，併爲用戶指出適當的重試/跟進行爲。通往安全區域的另一個環節往往是合適的。
完整名單將成爲發展進程。這對任何施工過程都是正常的。代碼中無法糾正的任何操作都應該由頁面生成代碼處理。這些可以通過記錄和生成適當的HTTP錯誤頁面來處理（已經在處理1中完成）。按類而不是特定的錯誤條件處理錯誤將是適當的。除非用戶可以自行更正，否則不應向用戶報告實際的錯誤情況。
對所有錯誤使用通用的catch代碼並按錯誤類進行響應。在許多情況下，您會希望在錯誤日誌中生成堆棧跟蹤。生成適當的HTTP錯誤代碼以供顯示。查看HTTP規範以確定要使用的相應HTTP響應。
表單驗證是一個單獨的類別，應在輸入驗證期間適當處理。這應該導致嵌入適當的錯誤消息的頁面重新顯示。

來源

2010-12-19 07:24:44 BillThor

在PHP網站上處理錯誤

回答

相關問題