8 Essential Defensive Programming Patterns for Spring Boot 3

1. Introduction

In application development the gap between code that runs in a development environment and code that survives in production lies in defensive programming. Traditional code assumes the "happy path"; defensive code assumes every possible error will occur.

2. Practical Cases

2.1 Optional‑based NPE Safety

Null‑pointer exceptions are the most common production failures in Java. Using Optional eliminates verbose null checks and makes the intent explicit.

@Service
@Transactional(readOnly = true)
public class UserService {
    private final UserRepository userRepository;
    private final UserFactory userFactory;
    private final AuditService auditService;

    // Example 1: Get user or default
    public User getUserOrDefault(final Long userId) {
        return userRepository.findById(userId)
                .filter(User::isActive)
                .filter(this::hasValidProfile)
                .orElseGet(() -> createDefaultUser(userId));
    }

    // Example 2: Safe display name
    public Optional<String> getUserDisplayName(final Long userId) {
        return userRepository.findById(userId)
                .map(User::getProfile)
                .map(UserProfile::getDisplayName)
                .filter(StringUtils::hasText)
                .map(this::sanitizeDisplayName);
    }
}

Initial Optional creation returns Optional.empty() when the user does not exist.

Conditional processing with filter replaces explicit null checks.

Safe navigation via chained map calls propagates emptiness automatically.

Lazy fallback with orElseGet creates a default object only when needed.

2.2 Collection Safety & Stream Processing

Traditional collection handling requires many nested null checks. Using Optional and the Stream API provides concise, null‑safe pipelines.

public List<String> getValidEmails(final List<User> users) {
    return Optional.ofNullable(users)
            .orElse(Collections.emptyList())
            .stream()
            .filter(Objects::nonNull)
            .filter(User::isActive)
            .map(User::getEmail)
            .filter(StringUtils::hasText)
            .filter(this::isValidEmail)
            .map(String::trim)
            .map(String::toLowerCase)
            .distinct()
            .collect(Collectors.toList());
}

Eliminates manual null checks for the collection and its elements.

Stream filters express validation steps clearly.

Built‑in distinct removes duplicates.

2.3 Configuration Properties & Validation

Configuration errors can cause runtime failures. Annotation‑driven validation guarantees correctness at startup.

@ConfigurationProperties(prefix = "app")
@Validated
public class AppConfig {
    @NotNull @Min(1000) @Max(300000)
    private Integer connectionTimeout = 30000;

    @NotEmpty
    private List<PaymentMethod> supportedMethods = Arrays.asList(CREDIT_CARD, BANK_TRANSFER);

    private Optional<String> webhookUrl = Optional.empty();

    @PostConstruct
    public void validate() {
        validatePaymentMethods();
        validateUrlFormats();
    }
}

Field‑level constraints prevent invalid values. Optional marks truly optional settings.

Cross‑field validation runs in @PostConstruct before the bean is used.

2.4 Asynchronous Operation Management

Complex async flows need structured fallback and retry logic.

@Async
public CompletableFuture<NotificationResult> sendNotification(NotificationRequest request) {
    return attemptEmailDelivery(request)
            .exceptionallyCompose(e -> attemptSmsDelivery(request))
            .thenCompose(result -> result.isSuccess()
                    ? CompletableFuture.completedFuture(result)
                    : attemptPushNotification(request))
            .exceptionally(e -> {
                retryQueue.schedule(request, calculateRetryDelay());
                return NotificationResult.failed("All methods exhausted");
            });
}

Linear fallback chain with exceptionallyCompose.

Retry queue with exponential back‑off.

2.5 Database Transaction Management

Transactional boundaries protect ACID guarantees. Using Optional and functional style makes the flow explicit.

@Service
@Transactional
public class OrderProcessingService {
    public Order processOrder(final OrderRequest request) {
        final String transactionId = generateTransactionId();
        return Optional.of(request)
                .filter(orderValidator::validateOrderRequest)
                .map(req -> createOrderEntity(req, transactionId))
                .map(this::reserveInventory)
                .map(this::processPayment)
                .map(this::assignShipping)
                .map(orderRepository::save)
                .map(this::publishOrderCreatedEvent)
                .orElseThrow(() -> new OrderProcessingException("Order validation failed"));
    }
}

Each map represents a distinct processing step.

Any exception triggers a rollback because of @Transactional.

2.6 Comprehensive Testing Patterns

Defensive code must be verified for both success and failure paths.

@Test
void shouldHandleNullUserIdGracefully() {
    when(userRepository.findById(null)).thenReturn(Optional.empty());
    when(userFactory.createUser()).thenReturn(createGuestUser());
    User result = userService.getUserOrDefault(null);
    assertThat(result).isNotNull();
    assertThat(result.getUsername()).isEqualTo("guest");
    verify(auditService).logUserCreation(null, "DEFAULT_USER_CREATED");
}

Tests cover null inputs, invalid collections, and exception scenarios.

2.7 Exception Handling & Circuit Breaker

Global exception handlers return consistent error responses, while a circuit‑breaker prevents cascading failures.

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(UserNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleUserNotFound(UserNotFoundException ex, WebRequest request) {
        ErrorResponse response = errorResponseFactory.createErrorResponse("USER_NOT_FOUND", ex.getMessage(), request.getDescription(false));
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(response);
    }

    @ExceptionHandler(CircuitBreakerOpenException.class)
    public ResponseEntity<ErrorResponse> handleCircuitBreakerOpen(CircuitBreakerOpenException ex, WebRequest request) {
        ErrorResponse response = errorResponseFactory.createErrorResponse("SERVICE_TEMPORARILY_UNAVAILABLE", "Service unavailable, please try later.", request.getDescription(false));
        return ResponseEntity.status(HttpStatus.SERVICE_UNAVAILABLE).body(response);
    }
}

Separate handlers for domain‑specific and infrastructure errors.

Circuit‑breaker annotation defines fallback logic.

2.8 Reactive Programming

Non‑blocking pipelines need their own defensive safeguards.

@Service
public class ReactiveUserService {
    public Mono<User> findUserById(final Long userId) {
        return Mono.justOrEmpty(userId)
                .filter(id -> id > 0)
                .flatMap(this::findUserInCache)
                .switchIfEmpty(findUserInDatabase(userId))
                .switchIfEmpty(findUserFromExternalService(userId))
                .doOnNext(user -> cacheUser(userId, user).subscribe())
                .doOnError(error -> logger.error("Error: {}: {}", userId, error.getMessage()));
    }
}

Input validation, cache fallback, external service fallback.

Error isolation with doOnError prevents whole stream failure.