CODEWITHSUNDEEP
javascriptjavaerror-handling
RuntimeError
RuntimeError

Reputation: 1390

Errorhandling in Javascript/Java application

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!

Upvotes: 7

Views: 1031

Answers (4)

Roman
Roman

Reputation: 5210

Validate in the Back-End

Validate your data in the back-end. All data-flows will pass the back-end to go into the database.

Why in the Back-End

Imagine you provide a public api of your back-end and you do only some validations in the front-end.

It is still possible to add data to your database because you provide a public api. Someone could just call your api like random-host:8080\delete\user\65434.

No Validation in the Front-End?

Sure! Do some validation - but these are for the user-experience of a "normal" client. With these validations your client don't need to wait for server-side validations because he can get a directly feedback from your front-end.

Upvotes: 2

Ralf Kleberhoff
Ralf Kleberhoff

Reputation: 7290

Main rules:

  • Do every necessary check in the backend: you never know if the request really comes from your frontend. So it's nice to have the frontend do some checks, but the backend is responsible for not letting nonsense pass into your database.
  • Whenever something goes wrong, tell your caller (the way that's supported by your technology, e.g. exceptions in Java, response codes over HTTP / HTTPS).
  • Make sure every problem is logged in one and only place with all the information necessary to analyse it later. This typically includes a stack trace, so should do logging in the backend just before passing the error result code to the frontend. Use an ERROR log-level here.
  • Place additional WARN and INFO entries into the log as far as they seem useful to the administrator running the application site.
  • While searching for bugs, it can be useful to add DEBUG logging to help yourself (the developer) understand what's going on in detail. But have the logging framework normally suppress these entries, otherwise the admin will be quite unhappy having to read through annoying amounts of (to him) irrelevant logs.

Upvotes: 2

Karol Dowbecki
Karol Dowbecki

Reputation: 44952

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/.

Upvotes: 2

John Humphreys
John Humphreys

Reputation: 39294

There are two things to consider here which are important.

  1. User Experience
  2. System Safety

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).

Upvotes: 3

Related Questions