ตัวจัดการที่เขียนไว้ แล้วไม่เคยได้ทำงานเลย

สวิตช์ในบทที่แล้วเปลี่ยนซองจดหมายให้ · ตอนนี้ถึงตาเราเขียนข้อความข้างในเอง

ระบบรู้อยู่แล้วว่าช่องไหนผิดเพราะอะไร · สิ่งที่ขาดคือคนที่หยิบความรู้นั้นใส่ลงใน body

เขียนตัวจัดการตัวแรก

ดักชนิดเดียว แล้วเติมคีย์ของตัวเองเข้าไปในรูปมาตรฐาน

package clinic.http

import org.springframework.http.HttpStatus
import org.springframework.http.ProblemDetail
import org.springframework.web.bind.MethodArgumentNotValidException
import org.springframework.web.bind.annotation.ExceptionHandler
import org.springframework.web.bind.annotation.RestControllerAdvice

@RestControllerAdvice
class ValidationAdvice {

    @ExceptionHandler(MethodArgumentNotValidException::class)
    fun onInvalid(e: MethodArgumentNotValidException): ProblemDetail {
        val body = ProblemDetail.forStatus(HttpStatus.BAD_REQUEST)
        body.title = "KAEN-ADVICE-RAN"
        body.detail = "คำขอมีช่องที่กรอกไม่ถูกต้อง"
        body.setProperty(
            "errors",
            e.bindingResult.fieldErrors.associate { it.field to (it.defaultMessage ?: "") },
        )
        return body
    }
}

@ExceptionHandler คือสิ่งที่ผูกตัวจัดการตัวนี้เข้ากับ exception ชนิดเดียว · ชนิดอื่นที่หลุดออกมาจะไม่ผ่านตัวนี้เลย

title ที่เขียนไว้ไม่ใช่ข้อความสำหรับผู้ใช้ · มันคือ marker · เราจะอธิบายเหตุผลของมันในอีกสองหัวข้อข้างล่าง

build เขียว · โปรแกรมสตาร์ตขึ้น · ไม่มีคำเตือนสักบรรทัด

แล้วยิงคำขอที่ผิดสามช่องเข้าไป

นี่คือจุดที่บทนี้มีอยู่เพื่อมัน

{"detail":"Invalid request content.","instance":"/bookings","status":400,"title":"Bad Request"}

สี่คีย์ · ไม่มีคีย์ errors · title เป็น Bad Request

ตัวจัดการที่เราเพิ่งเขียน ไม่ได้ทำงานเลยสักครั้ง

ทำไมเราถึงกล้าพูดแบบนั้น

เพราะรหัส 400 พิสูจน์ข้อนี้ไม่ได้ และ body ก็พิสูจน์ไม่ได้ ถ้าไม่มี marker

ถ้าตัวจัดการของเราทำงาน มันก็ตอบ 400 · ถ้ามันไม่ทำงาน Spring ก็ตอบ 400 อยู่ดี · รหัสตอบกลับแยกสองกรณีนี้ไม่ออก

marker คือค่าที่ไม่มีทางบังเอิญตรง ซึ่งเราวางไว้ในทางที่เราสงสัย · ถ้ามันโผล่ออกมา แปลว่าทางนั้นถูกเดิน · ถ้าไม่โผล่ แปลว่าไม่ถูกเดิน

KAEN-ADVICE-RAN ไม่มีทางเป็นค่าที่ Spring คิดขึ้นเอง · การที่มันไม่โผล่ จึงเป็นหลักฐาน ไม่ใช่ข้อสันนิษฐาน

🎯 ถามว่าใครตอบ ไม่ใช่ถามว่ามีคนตอบไหม

คำถามที่ตอบไม่ได้ด้วยรหัสตอบกลับ มีมากกว่าที่คนส่วนใหญ่คิด

คำถามที่ถามว่า “ทำงานไหม” ต้องการค่าที่ตอบได้แค่ทางเดียว · ไม่ใช่ค่าที่ทั้งสองทาง บังเอิญให้เหมือนกัน

หลักเดียวกันนี้ใช้กับการวัดทุกอย่างในคอร์สนี้ · probe ของคอร์สจึงบังคับให้ marker ต้องโผล่ในทรงที่ควรโผล่ และต้องไม่โผล่ในทรงที่ไม่ควร

เหตุผลที่มันไม่ได้รัน

@RestControllerAdvice ที่ไม่ระบุลำดับ ได้ลำดับต่ำสุด

Spring มีตัวจัดการของตัวเองสำหรับ MethodArgumentNotValidException อยู่แล้ว · นั่นคือตัวที่ตอบ Invalid request content. มาตั้งแต่บทที่ 2

เมื่อมีสองตัวรับชนิดเดียวกัน Spring เรียงตาม @Order แล้วเลือกตัวแรกที่เจอ · ตัวของ Spring อยู่ที่ลำดับ 0 · ตัวของเราที่ไม่ได้ประกาศอะไรเลย ได้ลำดับต่ำสุด

ไม่มีอะไรบอกเราว่ามีตัวอื่นแข่งอยู่ · ไม่มีคำเตือนตอนแปล ไม่มี log ตอนสตาร์ต ไม่มีอะไรตอนรัน

แก้ด้วยบรรทัดเดียว

ประกาศลำดับให้ต่ำกว่าของ Spring

package clinic.http

import org.springframework.core.annotation.Order
import org.springframework.http.HttpStatus
import org.springframework.http.ProblemDetail
import org.springframework.web.bind.MethodArgumentNotValidException
import org.springframework.web.bind.annotation.ExceptionHandler
import org.springframework.web.bind.annotation.RestControllerAdvice

@Order(-1)
@RestControllerAdvice
class ValidationAdvice {

    @ExceptionHandler(MethodArgumentNotValidException::class)
    fun onInvalid(e: MethodArgumentNotValidException): ProblemDetail {
        val body = ProblemDetail.forStatus(HttpStatus.BAD_REQUEST)
        body.title = "KAEN-ADVICE-RAN"
        body.detail = "คำขอมีช่องที่กรอกไม่ถูกต้อง"
        body.setProperty(
            "errors",
            e.bindingResult.fieldErrors.associate { it.field to (it.defaultMessage ?: "") },
        )
        return body
    }
}

ยิงคำขอเดิมเข้าไปใหม่

{"detail":"คำขอมีช่องที่กรอกไม่ถูกต้อง","errors":{"doctorId":"must not be blank","endMinute":"must be greater than or equal to 1","startMinute":"must be greater than or equal to 0"},"instance":"/bookings","status":400,"title":"KAEN-ADVICE-RAN"}

marker โผล่ · คีย์ errors โผล่ · และมันบอกครบทั้งสามช่องพร้อมเหตุผลของแต่ละช่อง

สี่ทรง เรียงตามลำดับที่เราเดินมา

ตารางนี้คือสามบทแรกของคอร์สทั้งหมด

ทรง	รหัส	content-type	ผู้เรียกรู้ว่าช่องไหนผิดไหม
ค่าตั้งต้น	400	`application/json`	ไม่
เปิด problemdetails	400	`application/problem+json`	ยังไม่
เพิ่ม advice ที่ไม่ระบุลำดับ	400	`application/problem+json`	ยังไม่ · advice ไม่ได้รันเลย
ใส่ `@Order(-1)` ให้ advice นั้น	400	`application/problem+json`	ใช่ · ครบสามช่อง

สี่แถวนี้ให้รหัสเดียวกันหมด · ถ้าเราวัดด้วยรหัสอย่างเดียว เราจะสรุปว่าไม่มีอะไร เปลี่ยนเลยตั้งแต่แถวแรก

⚠️ ลำดับสำคัญเฉพาะตอนที่มีคนแข่ง

@Order(-1) ไม่ใช่ของที่ต้องใส่ทุกครั้งที่เขียน advice · มันจำเป็นตรงนี้เพราะ Spring มีตัวจัดการของตัวเองสำหรับชนิดนี้อยู่แล้ว

บทที่ 4 จะเขียน advice อีกตัวที่ไม่ต้องใส่ @Order เลย และมันทำงานได้ทันที เพราะไม่มีใครแข่ง · ความต่างของสองกรณีนี้คือสิ่งที่ต้องเข้าใจ ไม่ใช่กฎที่ต้องท่อง

สรุปสิ่งที่วัดได้ในบทนี้

สามข้อ · และข้อที่สองคือข้อที่คนพลาดกันมากที่สุด

advice ที่ไม่ระบุลำดับ ไม่ได้รันเลย พิสูจน์ด้วย marker ที่ไม่โผล่ใน body
รหัสตอบกลับพิสูจน์เรื่องนี้ไม่ได้ ทั้งสี่ทรงตอบ 400 เหมือนกันหมด
ใส่ @Order(-1) แล้วได้คีย์ errors ครบสามช่อง พร้อมเหตุผลของแต่ละช่อง

บทที่ 4 จะย้ายไปที่ความล้มเหลวอีกชนิด ซึ่งบทที่ 2 พิสูจน์ไว้แล้วว่า สวิตช์ปกติครอบไม่ถึง

🔬 ตัวเลขทุกตัวในบทนี้มาจากไหน

สองทรงในบทนี้ต่างกันที่บรรทัด @Order(-1) กับ import ของมันเท่านั้น · probe มีข้อยืนยันที่แดงถ้าสอง source นี้ต่างกันเกินกว่านั้น
marker KAEN-ADVICE-RAN เป็นตัวเดียวกับที่ npm run verify:clinic-http ฝังไว้
Spring Boot 4.1.1 · Kotlin 2.4.10 · JDK 25
Spring Framework — Controller Advice (เข้าถึง 2026-09-02) — การเรียงลำดับของ advice หลายตัว
Ordered.LOWEST_PRECEDENCE (เข้าถึง 2026-09-02) — ค่าที่ bean ได้เมื่อไม่ประกาศลำดับ

เช็กความเข้าใจ — บทที่ 3

ข้อ 1 / 3

อะไรเป็นหลักฐานว่า advice ตัวแรกไม่ได้รัน

ตัว​จัดการ​ที่​เขียน​ไว้ แล้ว​ไม่​เคย​ได้​ทำงาน​เลย

เขียน​ตัว​จัดการ​ตัว​แรก

แล้ว​ยิง​คำขอ​ที่​ผิด​สาม​ช่อง​เข้าไป

ทำไม​เรา​ถึง​กล้า​พูด​แบบ​นั้น

เหตุผล​ที่​มัน​ไม่​ได้​รัน

แก้​ด้วย​บรรทัด​เดียว

สี่​ทรง เรียง​ตาม​ลำดับ​ที่​เรา​เดิน​มา

สรุป​สิ่ง​ที่​วัด​ได้​ใน​บท​นี้