在 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 時也會很困擾，總結來講，個人習慣並不偏好這種寫法。

• Do. Or Do Not. There Is No Try - Object#try Considered Harmful