C裡沒有異常沒有type deduction也無所謂建構函式，你的一個函式如果可能成功可能失敗，通用做法是返回一個狀態碼，真正的返回值用傳指標方式弄出去。這樣基本也就是C能做到的最好效果了。
C++裡則完全不同，雖然傳統方式差不多也是這樣的，特別是某style guide這種邪教資料四處氾濫破壞歷史發展程序的情況下。這個確實很無奈。C++標準前進的方向是該返回什麼就返回什麼，guaranteed copy elision、optional、structured binding、tuple都是可以使用的工具。直接返回該返回的物件優勢也很多，不需要這個物件default constructible（可能需要std::optional / boost::optional / exception式error reporting），可以auto推導型別方便重構，部分場景下可以改進效能等等。錯誤報告可以像boost一樣使用異常或者傳指標/引用的error code來實現，一般error code的型別不會沒事重構的。
最後，歸結到題目中的單鏈表find這個特定場景。熟悉STL的同學肯定第一反應是返回一個迭代器，對頭，這個場景確實應該返回迭代器，因為使用者找到這個元素之後下一個操作可能是對它進行修改，因此需要一個可以引用到這個元素記憶體地址的方式而不是元素的值本身，而find是可以合理失敗的（查詢落空），因此不適合返回引用也不適合拋異常。因此最簡單起見就返回一個指標是合適的。再先進一點可以給這個單鏈表實現一個迭代器，讓它的++運算子變更指向為連結串列下一個元素，等等。至於書裡返回的status，你一個單鏈表find還能查一半網路抽風查詢失敗麼？不可能吧。而如果記憶體已經corrupt了，你返回個status能救得了誰呢。所以這裡status是沒必要的，失敗原因只有可能是沒找到，一個指標夠用了。
PS：不要去學習嚴書的程式碼風格！這本書的程式碼如果你將它當真C++程式碼看，會發現程式碼風格非常糟糕。你最好把嚴書的程式碼當作單純是用於講解資料結構用的虛擬碼來看待。沒記錯的話書的序裡應該也是這麼建議的。
C裡沒有異常沒有type deduction也無所謂建構函式，你的一個函式如果可能成功可能失敗，通用做法是返回一個狀態碼，真正的返回值用傳指標方式弄出去。這樣基本也就是C能做到的最好效果了。
C++裡則完全不同，雖然傳統方式差不多也是這樣的，特別是某style guide這種邪教資料四處氾濫破壞歷史發展程序的情況下。這個確實很無奈。C++標準前進的方向是該返回什麼就返回什麼，guaranteed copy elision、optional、structured binding、tuple都是可以使用的工具。直接返回該返回的物件優勢也很多，不需要這個物件default constructible（可能需要std::optional / boost::optional / exception式error reporting），可以auto推導型別方便重構，部分場景下可以改進效能等等。錯誤報告可以像boost一樣使用異常或者傳指標/引用的error code來實現，一般error code的型別不會沒事重構的。
最後，歸結到題目中的單鏈表find這個特定場景。熟悉STL的同學肯定第一反應是返回一個迭代器，對頭，這個場景確實應該返回迭代器，因為使用者找到這個元素之後下一個操作可能是對它進行修改，因此需要一個可以引用到這個元素記憶體地址的方式而不是元素的值本身，而find是可以合理失敗的（查詢落空），因此不適合返回引用也不適合拋異常。因此最簡單起見就返回一個指標是合適的。再先進一點可以給這個單鏈表實現一個迭代器，讓它的++運算子變更指向為連結串列下一個元素，等等。至於書裡返回的status，你一個單鏈表find還能查一半網路抽風查詢失敗麼？不可能吧。而如果記憶體已經corrupt了，你返回個status能救得了誰呢。所以這裡status是沒必要的，失敗原因只有可能是沒找到，一個指標夠用了。
PS：不要去學習嚴書的程式碼風格！這本書的程式碼如果你將它當真C++程式碼看，會發現程式碼風格非常糟糕。你最好把嚴書的程式碼當作單純是用於講解資料結構用的虛擬碼來看待。沒記錯的話書的序裡應該也是這麼建議的。