Menu
I am working on my first application that combines Java and Javascript. Since it grows more and more, it is time to implement some proper error handling. But to be honest, I have zero experience.
My application simply allows a user to fill different formulars that are stored in a database. For the frontend, I use Angular. The database is MySQL, working with Hibernate and Spring.
There are already some checks in the frontend, for example verifying if the user typed a date that does not lie back more than 10 years. But what I think about is some kind of type checking. For example, if the received value is really a boolean and if not, throw an error.
The question is:
Where should this type checking be executed? Already in the frontend with Javascript (thinking of "typeof") or in the backend shortly before adding the received values to the database? And is it better to use Http status codes or writing errors to a log file?
Maybe you could recommend some best practices or options that work for you.
Thanks a lot!
540
JavaScript provides error-handling mechanism to catch runtime errors using try-catch-finally block, similar to other languages like Java or C#. try: wrap suspicious code that may throw an error in try block. catch: write code to do something in catch block when an error occurs.
Try catch statementsIf an exception is raised, the catch clause gets executed. In the example above, we have made a typo error while calling the in-built alert() function. We have misspelled alert to produce an error deliberately. The catch clause catches the error and executes the code.
Why do we need to handle errors in JavaScript? Unhandled JavaScript errors will stop the execution of your script, leaving the application in an undesired state – or, even worse, in an unknown state. So you need a robust error-handling process to avoid unknown errors in your apps.
There are two things to consider here which are important.
For users, you definitely want to validate early and often and preferably interactively. For example, your bank website won't let you put letters into your credit card number; it will definitely validate and make the box red as soon as you type it.
The back end has to be protected separately though because it could potentially be used from another source other than the front end. Also, you probably don't want to trust yourself to remember to update the UI validation to handle every potential back-end error.
There are plenty of decent validation libraries in NPM and Maven, so the code for most validations should be pretty trivial on both ends, and its probably safest to keep it in both.
You should always unit test each component separately and ensure its safe/functional in its own right before worrying about the overall system as a whole.
You should definitely use HTTP status codes to report back-end errors to the front end in any REST app, and try to use the correct ones (e.g. for not found, bad argument, not authorized, internal error). No matter what you do on the front end, you will have back-end errors to handle (e.g. bad SQL syntax, database connection failed).
146
You should implement all validation functionality in the backend, essentially never trusting the client data. If your API is publicly available on the Internet people will try to play with it, break it or hack it.
Also if you ever decide to write another client (e.g. Android app) the API can be safely reused between clients. Feel free to implement additional validation in the frontend to provide nicer user experience, but you can't skip backend validation.
Instead of developing your own API standard you might want to implement one of the existing standards e.g. https://jsonapi.org/.
29
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
