This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Argument in create/update longer than size of a field Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Argument in create/update longer than size of a field" Watch "Argument in create/update longer than size of a field" New topic
Author

Argument in create/update longer than size of a field

Paweł Baczyński
Bartender

Joined: Apr 18, 2013
Posts: 1020
    
  16

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


Formely Pawel Pawlowicz
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

I'd go for option 2.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5455
    
  13

2 is what I did!


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2564
    
    9

Instead of throwing an exception, do a length checker in the JTextField in the create/update form. This is what I did.


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5 OCPBCD5
Paweł Baczyński
Bartender

Joined: Apr 18, 2013
Posts: 1020
    
  16

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

Joined: Sep 13, 2007
Posts: 2564
    
    9

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

Joined: Dec 28, 2007
Posts: 2266
    
    3

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
Bartender

Joined: Jul 19, 2004
Posts: 5455
    
  13

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Argument in create/update longer than size of a field