Nic Lin's Blog

喜歡在地上打滾的 Rails Developer

盡可能的減少使用具感染性的 Try 或是 lonely/safe navigation operator

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

參考

comments powered by Disqus