在 Rails application 中，我們可以用 Object#try 來避免 NoMethodError 拋出，而當 recevier 發現該 method 不存在時，會直接回傳 nil，可以避免更冗長的判斷、額外的錯誤處理，聽起來確實更好了，同時，我認為是製造更多的問題。
# 原本的寫法
if user && user.eamil
# dosomething
end
# 用了 Try 以後
if user.try(:email)
# dosomething
end
看起來不錯吧？好像更簡潔了。
但這種情況還算可以接受，如果濫用呢？看看以下兩個例子
# 將每個有可能回傳 nil 的 method 串接起來
payment.client.try(:addresses).try(:first).try(:country).try(:name)
# 一個 Class 用 try 應付多種情況
class GoodService
def call(object)
object.save!
object.try(:send_success_notification, "saved from GoodService")
end
end
這樣 Try 到底會產生什麼問題呢？
程式碼意義非常不明確， try 的意思就是
這裡可能會是
NoMethodError, 但我不告訴你是NoMethodError的時候該怎麼辦，反正一律給你nil
以 payment.client.try(:address) 來說，如果這是合法的邏輯，有些 payment 就是沒有 client
- 那是不是可以針對這些特別的 payment 進行額外處理？
- 如果是 polymorphic relationship 那情況有可能更糟，也許是其他的 model 有實作而這裡沒有？
- 或是更嚴重的數據遺失問題，程式的 bug 導致數據儲存不正確，又或是被黑客刪掉資料？
在這個例子裡面其實有很多隱患，光看這段 code 也無法馬上知道用 try 的意圖是什麼，也會造成日後 debug 的困難
處理 exception 其實有更好的作法。
遵循 Law of Demeter 最小知識原則
假設 A 要問 B 一個問題，但是 B 得問 C 才知道答案。
那麼 A 不需要知道 B 還要去問 C，對 A 來說，只要問 B 就能知道答案了。
# 範例
A.askB #=> Answer
# 違反此原則的範例：
A.askB.askC #=> Answer
這個問題不在於程式要 . 多長，而在於和 Object 之間的耦合程度，所以說如果是做一些轉換和操作並沒有違反原則哦
# 這個例子並沒有違反原則，因為只是做轉換和操作而已
input.to_s.strip.split(" ").map(&:capitalize).join(" ")
遵循最小知識原則，可以避免緊耦合狀況發生。
幾個改進的方法，而你應該認真處理錯誤
就上述例子 payment.client.try(:address) 來說，一般改進的作法會是
邏輯上不應該有 nil 狀況的寫法（如果真的遇到 nil, 一定就是問題）
class Payment
def client_address
client.address
end
end
直接在 method 裡面處理 nil 狀況（意義明白，好讀）
class Payment
def client_address
return nil if client.nil?
client.address
end
end
Rails 的話可以直接用 delegate 做，而 allow_nil 用來確定你的邏輯是否可以接受 nil
class Payment
delegate :address, to: :client, prefix: true, allow_nil: true
end
或是直接在一開始拉資料時就確保資料範圍正確性，避免不必要的錯誤發生，因為有可能某些 payment 就是沒有 client，那麼避免這樣的錯誤，可以直接在拉資料的時候，確保找出來的資料都是有 client 的 payment
這樣一來，其他的 developer 也能夠更清楚為什麼要這樣寫
Payment.with_completed_transactions.find_each do |payment|
do_something_with_address(payment.client_address)
end
還有一種狀況是，確保資料型態正確時，也不應該用 Try，看看下面這樣的寫法，我們可以猜測會有一個 String 傳進來，但也有可能會被亂傳其他參數進來，我們將永遠不會知道。
params[:name].try(:upcase)
但我認為更好的作法，是在程式碼裡面告訴其他的 developer, 這裡有可能會有 nil，如果有不是 nil 的狀況，那就應該要有 Error exception。
return if params[:name].nil?
params[:name].to_s.upcase
做多型態的 service 時，也請不要用 Try，完全看不懂啊！（所以什麼 Object 會發通知，什麼不會？）
class GoodService
def call(object)
object.save!
object.try(:send_success_notification, "saved from GoodService")
end
end
這裡建議兩種更好的改進作法
直接做兩個 service，把責任區分清楚。
class GoodServiceA
def call(object)
object.save!
end
end
class GoodServiceB
def call(object)
object.save!
object.send_success_notification("saved from GoodService")
end
end
或是把 send_success_notification 單獨拉出來做
class GoodService
def call(object)
object.save!
object.send_success_notification("saved from GoodService")
end
end
def send_success_notification(string)
# dosomething
end
如果有興趣的話，還有 Null Object Pattern 可以參考，這邊就不多說明了。
小結
- Rails 裡面有
try() - Ruby 裡面則是有
&.(Version 2.3.0 之後，稱為 lonely/safe navigation operator)
&. 其實比 try() 好一些，在某些情況下還是會拋出 NoMethodError，但其實都還是很曖昧不明的寫法，在讀 code 時也會很困擾，總結來講，個人習慣並不偏好這種寫法。