Skip to main content


Showing posts from 2017

Replacing exceptions with error notifications during input validation in Java

In my previous article I wrote about an input validation design which replaces hard-to-maintain-and-test if-else blocks. However, as some readers pointed out, it has a drawback - if the input data has more than one validation errors, then the user will have to submit the request multiple times to find all of them. From a usability perspective this is not a good design. An alternative to throwing exceptions when we find a validation error is to return a Notification object containing the error(s). This will enable us to run all the validation rules on the user input, and catch all violations at the same time. Martin Fowler wrote an article detailing the approach. I highly recommend you to go ahead and give it a read, if you haven't done so already. In this article I will refactor my previous implementation to use Error Notification object to validate user inputs. As a first step, I will create an ErrorNotification object which encapsulates my application errors - public

Clean Code from the trenches - Validation

Let's directly start with an example. Consider a simple web service which allows clients to place order to a shop. A very simplified version of the order controller could look something like below - @RestController @RequestMapping(value = "/", consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE) public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService = orderService; } @PostMapping public void doSomething(@Valid @RequestBody OrderDTO order) { orderService.createOrder(order); } } And the corresponding DTO class - @Getter @Setter @ToString public class OrderDTO { @NotNull private String customerId; @NotNull @Size(min = 1) private List<OrderItem> orderItems; @Getter @Setter @ToString public static class OrderItem { private String menuId; private String description; private String

Dealing with Java's LocalDateTime in JPA

A few days ago I ran into a problem while dealing with a LocalDateTime attribute in JPA. In this blog post I will try to create a sample problem to explain the issue, along with the solution that I used. Consider the following entity, which models an Employee of a certain company - @Entity @Getter @Setter public class Employee { @Id @GeneratedValue private Long id; private String name; private String department; private LocalDateTime joiningDate; } I was using Spring Data JPA, so created the following repository - @Repository public interface EmployeeRepository extends JpaRepository<Employee, Long> { } I wanted to find all employees who have joined the company at a particular date. To do that I extended my repository from JpaSpecificationExecutor - @Repository public interface EmployeeRepository extends JpaRepository<Employee, Long>, JpaSpecificationExecutor<Employee> { } and wrote a query like below - @SpringBootTest

Subtyping in Java Generics

Consider the following block of Java code, which we all know as valid - We can do this because Long is a subtype of Number . However, the following will fail to compile - Allowing such assignments would have easily let programmers break the type safety guarantee provided by the Generics . One would then be able to do - From the above example, it is clear that Subtyping in Java Generics works differently than the usual class based Subtyping. A list of numbers cannot point directly to a list of longs even though Long is a subtype of Number . In order to get around this restriction, we will have to use an upper bounded wildcard - which will also allow us to refer to a list of floats as well. A List<? extends Number>   is then treated as something like a super type of both List<Long>  and List<Number> . In fact, as long as a type X  is a subtype of Number , List<? extends Number>  will be able to refer to List<X>  without any compilation errors