Day 3 Tight Coupling? , More abut Exceptions,
Olaoluwa Oke| 22 June 2025
When i first modeled the room Entity , I made it have an attribute where it holds the list of the member is the roomm -val members : List of Users , It just felt natural, But this previous winter , i took a design patterns class and intuitively , I just knew something was wrong , The gang of four guys would be mad
The first problem is MongoDB’s 16MB document size limit. Embedding a
growing list of users inside a single room document can
quickly approach that limit, especially in active or large rooms.
The bigger issue, though, was tight coupling. If a user's data changes (say they update their name or status), every room they’re embedded in would also need to be updated. This leads to redundancy, bloated updates, and potential data inconsistencies and these are symtomps of a tightly coupled system, That's that about flexible design pattern ,
Now when building a roommate management app like Awa or any other app for that matter , things don’t always go as planned(rarely goes as planned ).
A user might try to join a room with the wrong code or may try to join a non existent room. Or maybe trying to kick a user that is not in a room out (real). But when these errors happen , we now do not want the server to break down or stop
Instead of scattering try-catch statements throughout the entire codebase, we implemented a clean and scalable error-handling system using @ControllerAdvice, a powerful Spring Boot annotation that centralizes exception handling across all controllers.
And also to format errors better for front end guys (my guy)
The bigger issue, though, was tight coupling. If a user's data changes (say they update their name or status), every room they’re embedded in would also need to be updated. This leads to redundancy, bloated updates, and potential data inconsistencies and these are symtomps of a tightly coupled system, That's that about flexible design pattern ,
Now when building a roommate management app like Awa or any other app for that matter , things don’t always go as planned(rarely goes as planned ).
A user might try to join a room with the wrong code or may try to join a non existent room. Or maybe trying to kick a user that is not in a room out (real). But when these errors happen , we now do not want the server to break down or stop
Instead of scattering try-catch statements throughout the entire codebase, we implemented a clean and scalable error-handling system using @ControllerAdvice, a powerful Spring Boot annotation that centralizes exception handling across all controllers.
Why Global Error Handling?
As the project grows, the number of possible exceptions that can occur will increase. Therefore, to reduce this problem and simplify error management as much as possible, I had to build some certain structures and i had to build a Global Exception handler, This reall just help bubble errors encountered in the Service layer or even any where for that matter , Filters , Bublle it down back to the Exception Handler , , In the Exception Handler , you would have a handle method that handles everytype of exception that you might have , and you would annotate that with ... quite directly @ExceptionHandler annotation You would make each class of these error types ( that end up being parameters in the ExceptionHandler method) and make them extenc what type of error they are , Usually , Runtime ExceptionsAnd also to format errors better for front end guys (my guy)
References
0
Page 1 of 1
© Melancholy Mornings
