บ่อยครั้งเวลาเห็น function ที่มีการ return ค่า error ออกมาพร้อมค่า boolean แล้วมักจะเจอว่า โค้ดจะอ่านยากขึ้นมาก และชวนงง ผมยกตัวอย่างเลยละกัน
func callService(req userRequest) (error, bool) {}
คนที่เขียนนี้เขาน่าจะรู้ความหมายของค่า bool นี้ ก็เลยตั้งชื่อตัวแปรที่รับมาแบบนี้
func Service() (error, bool) {
...
err, isSuccess := callService(req)
...
}
แต่ทีนี้ ผมก็เห็นบ่อยอีกเช่นกัน ที่เจ้าฟังก์ชั่นที่เรียก callService ก็อยากจะคืนค่า boolean ออกไปเหมือนกัน แต่คราวนี้เขาเขียนแบบนี้
err, isFail := Service()
พอเห็นแบบนี้ ผมต้องไปนั่งอ่านเงื่อนไขในแต่ละฟังก์ชั่นอีกหลายรอบ แล้วก็มึนอยู่นาน เพราะในเงื่อนไขส่วนใหญ่ใน callService ถ้ามี error ค่า bool มักจะเป็น false และเงื่อนไขส่วนใหญ่ใน Service ถ้ามี error ค่า bool มักจะเป็น true
แต่ก็ไม่เสมอไปด้วย มันมักจะมีอยู่บรรทัดหนึ่งที่ใน callService อยากจะคืนค่า error เป็น nil และค่า bool เป็น false ซึ่งผมตีความมันไม่ได้ และถามใครก็ตอบยาก แม้แต่บางทีถามคนที่เขียนมันขึ้นมาเอง ก็ยังตอบไม่ได้ด้วย
แล้วลองนึกถึงว่า Service ก็มีเหมือนกันที่อยากจะคืน error แต่ bool เป็น false มันหมายความว่า มี error แล้วก็ success ด้วยเหรอ!!!
ส่วนตัวผมอยากแนะนำว่า เวลาเขียนฟังก์ชั่นที่มีค่า error คืนออกมาแล้ว พยายามใช้มันให้เกิดประโยชน์ ถ้ามันจะ error ก็ตรวจสอบที่ค่า error ไปเลย
ส่วนใหญ่คนที่เขียนฟังก์ชั่นที่คืนออกมา 2 อย่างนี้ มักจะสับสนระหว่าง error ที่เกิดจากความผิดพลาดจริงๆ กับ business error ซึ่งกรณี business error มักจะรู้จากการนำเอาข้อมูลมาตรวจสอบ แล้วพบว่าตาม requirement แล้วมันถือว่าไม่ถูกต้องเช่น data ที่ได้มา ผิด format หรือได้ข้อมูลมาไม่ครบ หรืออื่นๆ แต่พอเราพยายามจะเหมารวมสิ่งนี้เป็น error ไปด้วย เราก็เริ่มสับสน แล้วก็เลยสร้างค่า bool ขึ้นมาเพื่อหวังว่าจะแยก 2 เรื่องนี้ออก แต่มันจะยิ่งกลับทำให้ งง และสับสนแทน
คำแนะนำคือ error ให้ treat มันเป็น error ส่วน business error จำเป็นตรงคุยกับคนที่ให้ requirement ว่ากรณีแบบนี้ สุดท้ายเราจะจัดการกับมันแบบไหน ใครควรรับรู้ ใครควรแก้ไข แล้วจะแสดงให้เขาเห็นได้ในช่องทางไหนเช่น ถ้า log ไว้ แล้วจะให้ log แบบไหน ใครจะมาดู หรือระบบไหนจะมาหยิบไปทำ เรื่องนี้ควรต้องคุยให้ชัดครับ
หวังว่าจะเป็นประโยชน์นะครับ
Top comments (0)