09.06 Error Handling Best Practices

---

📌 At a Glance

รายการ	รายละเอียด
Topic	Error Handling Best Practices
Difficulty	⭐⭐ Intermediate
Reading Time	10 นาที
Target	Developer, System Integrator
Related APIs	All APIs

---

🎯 Learning Objectives

หลังจากศึกษาหัวข้อนี้แล้ว ผู้อ่านจะสามารถ

• ออกแบบระบบที่รองรับข้อผิดพลาดได้อย่างมีประสิทธิภาพ
• ลดผลกระทบจากการเกิดข้อผิดพลาดระหว่างการเชื่อมต่อ
• วางแนวทาง Retry และ Logging ได้อย่างเหมาะสม
• เตรียมระบบสำหรับการใช้งานในระดับ Production

---

Overview

การจัดการข้อผิดพลาดไม่ได้หมายถึงการแสดงข้อความ Error ให้ผู้ใช้งานเท่านั้น แต่รวมถึงการออกแบบระบบให้สามารถตรวจจับ วิเคราะห์ บันทึก และตอบสนองต่อข้อผิดพลาดได้อย่างเหมาะสม

Client System ควรแยกประเภทของข้อผิดพลาด และกำหนดแนวทางการดำเนินการที่แตกต่างกัน เช่น การแก้ไขข้อมูล การ Retry หรือการแจ้งเตือนผู้ดูแลระบบ

แนวทางดังกล่าวจะช่วยเพิ่มความเสถียรของระบบ ลดการหยุดชะงักของกระบวนการทำงาน และเพิ่มความน่าเชื่อถือของการเชื่อมต่อกับ SISAHYGO API

---

Figure 9-6 Error Handling Best Practices

Figure 9-6 แสดงแนวทางการจัดการข้อผิดพลาดที่แนะนำสำหรับระบบ Production ตั้งแต่การรับ Response การวิเคราะห์ข้อผิดพลาด การดำเนินการแก้ไข และการบันทึกข้อมูลเพื่อการตรวจสอบย้อนหลัง

---

Recommended Error Handling Workflow

API Request

      │

      ▼

Receive HTTP Response

      │

      ▼

Check Status Code

      │

      ├────────► 2xx

      │               │

      │               ▼

      │         Continue Process

      │

      ▼

4xx / 5xx

      │

      ▼

Read Error Response

      │

      ▼

Determine Error Type

      │

      ├────────► Authentication

      │

      ├────────► Validation

      │

      ├────────► Business Rule

      │

      └────────► Server Error

      │

      ▼

Take Appropriate Action

---

Recommended Actions by Error Type

Error Type	Recommended Action
Authentication	ตรวจสอบ API Key และสิทธิ์การใช้งาน
Validation	แก้ไขข้อมูลก่อนส่งใหม่
Business Rule	ตรวจสอบเงื่อนไขทางธุรกิจและข้อมูลอ้างอิง
Server Error	Retry ภายหลังและบันทึกเหตุการณ์
Network Error	ตรวจสอบการเชื่อมต่อและ Retry ตามช่วงเวลา

---

Retry Strategy

ไม่ใช่ทุกข้อผิดพลาดที่ควร Retry

HTTP Status	Retry
200	❌
201	❌
400	❌
401	❌
403	❌
404	❌
422	❌
429	✅ หลังจากหน่วงเวลา
500	✅
503	✅

สำหรับ 429, 500 และ 503 ควรใช้ Exponential Backoff เพื่อลดภาระของระบบ

---

Bulk Retry Recommendation

สำหรับ Bulk Submission ไม่ควร Retry ทั้ง Batch โดยอัตโนมัติ หากมีบางรายการไม่สำเร็จ

Client System ควรอ่านผลลัพธ์จาก results[] แล้ว Retry เฉพาะรายการที่มีสถานะ failed เท่านั้น เพื่อป้องกันการสร้างข้อมูลซ้ำ

Logging Recommendations

ทุกครั้งที่เกิดข้อผิดพลาด ควรบันทึกข้อมูลอย่างน้อยดังนี้

Information	Purpose
Timestamp	ระบุเวลาที่เกิดเหตุการณ์
Endpoint	ระบุ API ที่เรียกใช้งาน
HTTP Status	วิเคราะห์ประเภทของข้อผิดพลาด
Error Code	อ้างอิงข้อผิดพลาด
Client Reference	เชื่อมโยงกับเอกสารต้นทาง
Request ID (ถ้ามี)	ใช้ติดตามเหตุการณ์
Response Body	ใช้วิเคราะห์ปัญหา

---

User Experience Recommendations

เมื่อเกิดข้อผิดพลาด

• แสดงข้อความที่เข้าใจง่าย
• ระบุข้อมูลที่ผู้ใช้ต้องแก้ไข
• ไม่แสดงรายละเอียดภายในระบบ เช่น Stack Trace หรือ SQL Error
• แนะนำขั้นตอนถัดไป เช่น "ตรวจสอบข้อมูลแล้วลองใหม่"

---

Monitoring Recommendations

ระบบ Production ควรมีการติดตามเหตุการณ์ เช่น

• จำนวน Authentication Errors
• จำนวน Validation Errors
• จำนวน Server Errors
• อัตราความสำเร็จของ API Calls
• เวลาตอบสนองเฉลี่ย (Response Time)

ข้อมูลเหล่านี้ช่วยให้สามารถตรวจพบปัญหาได้ตั้งแต่ระยะเริ่มต้นและวางแผนปรับปรุงระบบได้อย่างต่อเนื่อง

---

Production Checklist

ก่อนนำระบบขึ้นใช้งานจริง

• [x] ตรวจสอบ HTTP Status Codes
• [x] รองรับ Standard Error Response
• [x] แยกการจัดการ Error ตามประเภท
• [x] ใช้ Retry เฉพาะกรณีที่เหมาะสม
• [x] บันทึก Error Log
• [x] ใช้ HTTPS
• [x] เก็บ API Key อย่างปลอดภัย
• [x] แสดงข้อความ Error ที่เหมาะสมแก่ผู้ใช้งาน

---

Common Mistakes

Problem	Recommendation
Retry ทุก Error	Retry เฉพาะข้อผิดพลาดที่เหมาะสม
แสดงข้อความจาก Server โดยตรง	แสดงข้อความที่เหมาะสมกับผู้ใช้งาน
ไม่บันทึก Error Log	บันทึกทุกเหตุการณ์สำคัญ
ไม่ตรวจสอบ HTTP Status	ตรวจสอบก่อนประมวลผล Response
เก็บ API Key ใน Source Code	ใช้ Environment Variables หรือ Secret Manager

---

Related Sections

• 09.02 HTTP Status Codes
• 09.03 Standard Error Response Format
• 09.04 Authentication & Connection Verification
• 09.05 Validation Errors

---

Summary

การจัดการข้อผิดพลาดที่ดีเป็นองค์ประกอบสำคัญของระบบ Integration ระดับ Production โดยควรแยกประเภทของข้อผิดพลาด กำหนดแนวทางการดำเนินการที่เหมาะสม ใช้ Retry อย่างมีหลักการ บันทึกข้อมูลเพื่อการวิเคราะห์ และออกแบบประสบการณ์ผู้ใช้งานให้สามารถแก้ไขปัญหาได้อย่างสะดวก แนวทางเหล่านี้จะช่วยให้การเชื่อมต่อกับ SISAHYGO API มีความเสถียร ปลอดภัย และพร้อมรองรับการใช้งานในระยะยาว

---

Next Step

➡️ 09.07 Chapter Summary