Php錯誤處理

Php錯誤級別:

E_ERROR 致命錯誤,會終止指令碼執行.值為1

E_WARNING 警告錯誤,給出提示,不會終止執行值為2

E_PARSE 編譯時的語法解析錯誤,解析錯誤僅僅由分析器產生。值為4

E_NOTICE 執行時通知錯誤,表示指令碼可能會遇到錯誤的情況 值為8

E_CORE_ERROR 在PHP初始化啟動過程中發生的致命錯誤。該錯誤類似 E_ERROR，但是是由PHP引擎核心產生的。 值為16

E_CORE_WARNING PHP初始化啟動過程中發生的警告 (非致命錯誤) 。類似 E_WARNING，但是是由PHP引擎核心產生的。 值為32

E_COMPILE_ERROR  致命編譯時錯誤。類似E_ERROR, 但是是由Zend指令碼引擎產生的。值為64

E_COMPILE_WARNING 編譯時警告 (非致命錯誤)。類似 E_WARNING，但是是由Zend指令碼引擎產生的。值為128

E_USER_ERROR 使用者產生的錯誤資訊。類似 E_ERROR, 但是是由使用者自己在程式碼中使用PHP函式 trigger_error()來產生的。值為256

E_USER_WARNING 使用者產生的警告資訊。類似 E_WARNING, 但是是由使用者自己在程式碼中使用PHP函式 trigger_error()來產生的。值為512

E_USER_NOTICE 使用者產生的通知資訊。類似 E_NOTICE, 但是是由使用者自己在程式碼中使用PHP函式 trigger_error()來產生的。值為1024

E_STRICT 啟用 PHP 對程式碼的修改建議，以確保程式碼具有最佳的互操作性和向前相容性。值為2048

E_RECOVERABLE_ERROR可被捕捉的致命錯誤。 它表示發生了一個可能非常危險的錯誤，但是還沒有導致PHP引擎處於不穩定的狀態。 如果該錯誤沒有被使用者自定義控制代碼捕獲 (參見 set_error_handler())，將成為一個 E_ERROR　從而指令碼會終止執行。值為4096

E_DEPRECATED 執行時通知。啟用後將會對在未來版本中可能無法正常工作的程式碼給出警告。值為8192

E_USER_DEPRECATED使用者產少的警告資訊。 類似 E_DEPRECATED, 但是是由使用者自己在程式碼中使用PHP函式 trigger_error()來產生的。 值為16384

E_ALL   表示E_STRICT除外的所有錯誤和警告資訊。 值為 30719  

使用位運算子組合顯示或遮蔽的錯誤(二進位制許可權判斷)

Php有關於錯誤的配置

error_reporting 設定錯誤報告的級別,級別設定可看上面

其預設值為 E_ALL & ~E_NOTICE,表示顯示除了E_NOTICE以及E_STRICT的所有錯誤

E_STRICT錯誤級別不包含在E_ALL裡,必須自己明確啟用該級別才能出現

在php以外使用錯誤級別常量是沒有意義的,可以用十進位制數字代替,比如2147483647 包含了所有的錯誤

display_errors 是否將錯誤輸出到螢幕上

雖然可以使用ini_set重新設定,但是當php發生致命錯誤時,是無法設定的

display_startup_errors 是否顯示啟動時的錯誤

log_errors  是否將指令碼的錯誤資訊記錄到log

log_errors_max_len 

設定 log_errors 的最大位元組數. 在 error_log 會新增有關錯誤源的資訊。預設值為1024，如果設定為0表示不限長度。該長度設定對記錄的錯誤，顯示的錯誤，以及 $php_errormsg都會有限制作用。

ignore_repeated_errors 

不記錄重複的錯誤資訊,

ignore_repeated_source 

忽略重複訊息時，也忽略訊息的來源。當該設定開啟時，重複資訊將不會記錄它是由不同的檔案還是不同的原始碼行產生的。

report_memleaks

如果這個引數設定為Off，則記憶體洩露資訊不會顯示 (在 stdout 或者日誌中)。This report will be send to stderr on Posix platforms. On Windows, it will be send to the debugger using OutputDebugString(), and can be viewed with tools like » DbgView。這隻對除錯編譯有效，而且需要 error_reporting 包含了 E_WARNING 才會起作用

track_errors 

如果開啟，最後的一個錯誤將永遠存在於變數 $php_errormsg 中。

html_errors

在錯誤資訊中關閉HTML標籤。這種新的HTML格式的錯誤資訊是可以點選，它引導使用者前往描述該錯誤或者導致該錯誤發生的函式的參考資訊頁面。 這些參考與 docref_root 和 docref_ext 的設定有關。

error_prepend_string string

錯誤資訊之前輸出的內容。

error_append_string string

錯誤資訊之後輸出的內容。

error_log 

設定指令碼錯誤將被記錄到的檔案。該檔案必須是web伺服器使用者可寫的。如果特殊值 syslog 被設定，則將錯誤資訊傳送到系統日誌記錄器。在Unix以及類似系統上，使用的是 syslog(3) ，而在 Windows NT 類系統上則為事件日誌。Windows 95上不支援系統日誌記錄。參見： syslog(). 如果該配置沒有設定，則錯誤資訊會被髮送到 SAPI 錯誤記錄器。例如，出現在Apache的錯誤日誌中，或者在CLI中傳送到stderr。

錯誤處理相關方法以及用法個人理解

debug_backtrace — 產生一條回溯跟蹤(backtrace) 可設定引數限制返回的堆疊數量,

可以查出呼叫該函式的堆疊資訊,對查錯很有幫助,和tp的debug類似

debug_print_backtrace();直接列印回溯,和debug_backtrace類似,

error_clear_last — 清除最近一次錯誤

error_get_last — 獲取最後發生的錯誤

error_log — 傳送錯誤資訊到某個地方,可將錯誤存進一個檔案,但是錯誤資訊不能有null

error_reporting — 設定應該報告何種 PHP 錯誤,和php.ini 一樣

restore_error_handler — 還原之前的錯誤處理函式,

restore_exception_handler — 恢復之前定義過的異常處理函式。

set_error_handler — 設定使用者自定義的錯誤處理函式,需要在錯誤之前就定義

以下級別的錯誤不能由使用者定義的函式來處理： E_ERROR、 E_PARSE、 E_CORE_ERROR、 E_CORE_WARNING、E_COMPILE_ERROR、 E_COMPILE_WARNING，和在 呼叫 set_error_handler() 函式所在檔案中產生的大多數 E_STRICT。

就像error_reporting 的 ini 設定能夠控制錯誤的顯示一樣， 第2個引數能夠用於遮蔽 error_handler 的觸發。 如果沒有該掩碼， 無論error_reporting 是如何設定的， error_handler 都會在每個錯誤發生時被呼叫。

set_exception_handler — 設定使用者自定義的異常處理函式

trigger_error — 產生一個使用者級別的 error/warning/notice 資訊

user_error — trigger_error 的別名

register_shutdown_function  在php終止指令碼之後執行的註冊函式,第一個引數支援函式,以及一個包含例項化類的語句,類方法的陣列(註冊時會先例項化該類);(只要註冊成功,啥錯誤都可以捕獲)

Php自動載入

個人見解

spl_autoload_register 和__autoload主要區別在於

__autoload 只是個函式 只能在php中定義一次,如果要載入外掛等,需要不斷的if else判斷,或者是composer,將會很麻煩

spl_autoload_register 可以根據資料夾,或外掛,自定義各種處理函式,創造一個自動載入的佇列,會根據佇列一直找下去;直到佇列完畢或者返回true(找到檔案預設返回true)

堆疊記憶體(個人理解)

堆:存放使用者定義變數的

棧:在函式中定義的一些基本型別變數,物件的引用變數,都在棧空間,超出該作用域時將會自動釋放

資料補充:

堆:

當在檔案中定義的變數被static修飾之後,將改變到全域性資料區,不佔用堆疊記憶體

棧:

棧記憶體一般儲存的是函式的呼叫資訊和函式中申明的變數，因為函式的呼叫是遞迴的，外層函式一定比內層被呼叫的函式先載入和執行，而一定等到內層被呼叫函式結束後才能結束，這個先進後出的機制就是為什麼叫棧記憶體的原因。

PS：在編譯時編譯器會先收集此函式中所有定義的變數，將他們放在函式最前面申請記憶體，所以他們進出棧的順序不是你在編寫程式時定義的順序，而是在函式執行前進棧，函式執行完成後出棧。

其他:

Const,global,static修飾之後都存放在全域性資料區

超全域性變數,全域性變數,都屬於靜態變數,存放在全域性資料區

資料較少,等待糾正以及完善

Phpweb執行模式

Php執行模式:

1）CGI（通用閘道器介面/ Common Gateway Interface）

一般是可執行程式，例如EXE檔案，和WEB伺服器各自佔據著不同的程序,而且一般一個CGI程式只能處理一個使用者請求。這樣，當用 戶請求數量非常多時，會大量佔用系統的資源，如記憶體、CPU時間等，造成效能低下。

1. 2.FastCGI（常駐型CGI / Long-Live CGI）

FastCGI是CGI的升級版本，FastCGI像是一個常駐 (long-live)型的 CGI，它可以一直執行著，只要啟用後，不會每次都要花費時間去Fork 一次 （這是 CGI 最為人詬病的 fork-and-execute 模式）。 

FastCGI是一個可伸縮地、高速地在HTTP server和動態指令碼語言間通訊的介面。多數流行的HTTP server都支援FastCGI，包括Apache、Nginx和lighttpd等，同時，FastCGI也被許多指令碼語言所支援，其中就有PHP。 

FastCGI介面方式採用C/S結構，可以將HTTP伺服器和指令碼解析伺服器分開，同時在指令碼解析伺服器上啟動一個或者多個指令碼解析守護程序。當HTTP伺服器每次遇到動態程式時，可以將其直接交付給FastCGI程序來執行，然後將得到的結果返回給瀏覽器。這種方式可以讓HTTP伺服器專一地處理靜態請求或者將動態指令碼伺服器的結果返回給客戶端，這在很大程度上提高了整個應用系統的效能。  

Php-fpm 是php中自帶的fastcgi管理器

3）CLI（命令列執行 / Command Line Interface）

1. 4.Web模組模式（Apache等Web伺服器執行的模式) 

 該模式是apache在cgi基礎上的一個擴充套件

1. 5.ISAPI（Internet Server Application Program Interface)是微軟提供的一套面向WEB服務的API介面，它能實現CGI提供的全部功能，並在此基礎上進行了擴充套件，如提供了過濾器應用程式接 口。ISAPI應用大多數以DLL動態庫的形式使用，可以在被使用者請求後執行，在處理完一個使用者請求後不會馬上消失，而是繼續駐留在記憶體中等待處理別的 使用者輸入。此外，ISAPI的DLL應用程式和WEB伺服器處於同一個程序中，效率要顯著高於CGI。

Php2種與web伺服器互動:

Nginx:

使用者發起請求,以nginx現行握手,當nginx接收到之後,推送給php-fpm進行處理,當php-fpm繁忙時,nginx將返回504 getway 

Apache:

Apache有3種執行模式,prefork,worker,Event,

根據不同的模式而建立不同的處理程序以及執行緒,接收到有關php時則交給apache模組處理