• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Argument in create/update longer than size of a field

 
Paweł Baczyński
Bartender
Posts: 1878
35
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the best course of action if e.g. name of a Location provided in create/update method is longer than the maximum capacity of a field.
I see two options but I can't decide
1. trim it and insert
2. throw an IllegalArgumentException
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd go for option 2.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
2 is what I did!
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Instead of throwing an exception, do a length checker in the JTextField in the create/update form. This is what I did.
 
Paweł Baczyński
Bartender
Posts: 1878
35
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
K. Tsang wrote:Instead of throwing an exception, do a length checker in the JTextField in the create/update form. This is what I did.

Yes, I will do that, too.
But when programming server side you can never assume that a client will always send you proper data.
Someone might create a different client than mine and send me a location with a length of 10000 characters. Then what?
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pawel Pawlowicz wrote:Someone might create a different client than mine and send me a location with a length of 10000 characters. Then what?


Honestly, I didn't do server side length validation. If you must throw an meaning exception like InvalidLengthException rather than IllegalArgumentException. If you do this make sure you don't break the method signature.

One reason to bypass this is to state that the Data class is not meant to run as a (web) "service".
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I'd say that a good reason to throw an IllegalArgumentException is to keep encapsulation in the Data class: the create/update methods know how to validate their data. Other than that, by having the create/update methods validate their parameters, you increase its reuse. Even if you reuse the Data class in other contexts, it is guaranteed that the data is always validated before being persisted, no matter if someone already validated something, or even if someone forgot to validate something.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have both: client side limitation and server side validation. You always have to implement server side validation, because the server protects the data integrity of your database (file) and that's the most important thing! Client side limitation can be added if you want for a better user experience.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic