🛠️
Validation & Error Handling

Custom Validators

Apna Validation Logic Banao
💡 Custom validator, EK SPECIALIZED INSPECTOR hai, JO, STANDARD CHECKLIST (BUILT-IN annotations) SE, BAAHAR ki, SPECIFIC, BUSINESS-RULE CHECKS karta hai — jaise EK PRODUCT CODE, EK PARTICULAR COMPANY FORMAT FOLLOW karta hai YA NAHI.

JAB, BUILT-IN VALIDATION ANNOTATIONS (jaise @Pattern), COMPLEX, BUSINESS-SPECIFIC RULES EXPRESS NAHI kar sakte, CUSTOM VALIDATORS BANAE ja sakte hain — @Constraint annotation SE, EK NAYA ANNOTATION DEFINE karके, aur ConstraintValidator interface IMPLEMENT karके.

Custom validator, DATABASE CHECKS bhi kar sakta hai — jaise EK EMAIL, ALREADY REGISTERED hai YA NAHI, CHECK karna (@UniqueEmail) — YE, SIMPLE, DECLARATIVE ANNOTATIONS SE, POSSIBLE NAHI hai, kyunki, UNKO, DATABASE ACCESS ki, ZAROORAT PADТI hai.

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = UniqueEmailValidator.class)
public @interface UniqueEmail {
    String message() default "Email already registered";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

@Component
public class UniqueEmailValidator implements ConstraintValidator<UniqueEmail, String> {
    private final UserRepository userRepository;

    public boolean isValid(String email, ConstraintValidatorContext context) {
        return !userRepository.existsByEmail(email);
    }
}

// Usage:
public class UserCreateDto {
    @UniqueEmail
    @Email
    private String email;
}
🛠️
Custom validator, EK SPECIALIZED INSPECTOR hai, JO, STANDARD CHECKLIST (BUILT-IN annotations) SE, BAAHAR ki, SPECIFIC, BUSINESS-RULE CHECKS karta hai — jaise EK PRODUCT CODE, EK PARTICULAR COMPANY FORMAT FOLLOW karta hai YA NAHI.
1 / 2
⚡ झट से Recap
  • @Constraint + ConstraintValidator = custom, business-specific validation rules
  • Database checks (jaise unique email) = custom validators mein POSSIBLE
  • Custom validators, Spring-managed hain — DI use kar sakte hain
इस page में (2 subtopics)

Custom VALIDATORS, SIRF, SINGLE FIELDS PAR HI NAHI, POORI, CLASS PAR bhi, APPLY ho sakte hain — jaise, "startDate, endDate SE, PEHLE, HONI CHAHIYE" — YE, MULTIPLE, FIELDS ke, BEECH, RELATIONSHIP CHECK karta hai, ISLIYE, CLASS-LEVEL, ANNOTATION, ZAROORI hai.

@Target(ElementType.TYPE)
@Constraint(validatedBy = ValidDateRangeValidator.class)
public @interface ValidDateRange { String message() default "endDate must be after startDate"; }

EK, WELL-DESIGNED, CUSTOM VALIDATOR (jaise, @ValidPhoneNumber), MULTIPLE, DIFFERENT DTOs mein, REUSE, ho sakta hai — jaise, UserCreateDto, aur, ContactUpdateDto, DONO mein, phoneNumber FIELD PAR, SAME, VALIDATOR, LAGAYA ja sakta hai.

💡Tip: Validators, COMMON, "shared" PACKAGE mein, RAKHNA, BEST PRACTICE hai, TAAKI, POORE, PROJECT mein, CONSISTENTLY, REUSE ho sakein.