Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: handling of Remote- and ParseException

 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I have some two questions concerning the handling of certain exceptions:
1. RemoteException.
I have the intention to handle this exception explicitly at the client's GUI, like:

I don't know if this is an appropriate approach, Max for example doesn't handle explicitly remote exceptions in his book. But I think the GUI client should know that something with the remote connection went wrong.
Comments?
2. Concerning the java.text.ParseException.
In my RoomAdapter-Class I have a private validateDate(String date)-method which may throw the checked ParseException:

The ParseException is thrown "if the beginning of the specified string cannot be parsed", that means if the String value doesn't match the format "yyyy/MM/dd".
I don't make any input validation at the Server-side, except checking if the length of the String-values don't surpass the length predefined by the schema description.
In my RoomAdapter-Class, which is at the client side (I have the 2-tier approach), besides the mentioned date-validation, I only make a validation of the CustomerID, if it's a eight-digit number. All the data in the other fields should have come from the server itself.
Thus I could argue that the ParseException signals an implementation error and I could chain my ParseException in a RuntimeException? Or should I just throw the checked ParseException back to the client, wrap it there in the generic GUIException and don't handle this exception explicitly at the View's side?
Comments?
Thanks in advance
Ulrich
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
Help me, please
Ulrich
 
Stephen Galbraith
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulrich,
on point 1
yeah, why not let them know!
on point 2
I think you should ask, can the caller of this method do anything to recover from this (or even the end user)? (checked)
Could it be an illegal argument (i.e. they've broken the contract implicit to calling this method)? (error)
The action that you take depends on the answer!
One thing in additon though, You said "I only make a validation of the CustomerID, if it's a eight-digit number" - although my reading of URLyBird (is this the same one?) is that the field length is 8-digits - I didn't see any reference to ensureing that the customerID MUST be 8 digits (wouldn't less still work?)
Of course a real "cop-out" solution is just to document that you'll leave it up to the systems administrator to remove any rooms that don't meet the 48hr criteria and then ignore it from then on
Steve
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stephen,
thanks for your answer.
I think you should ask, can the caller of this method do anything to recover from this (or even the end user)? (checked)
Could it be an illegal argument (i.e. they've broken the contract implicit to calling this method)? (error)
The action that you take depends on the answer!

Thus with the above argumentation and your comments I can justify my decision to wrap it in a unchecked Exception. Because the User can't modify the date field, I have the guarantee that the existing date values will correspond to the given format.
If in future, some new business methods will enable the modification of the date field, then I should have a input validation corresponding to the "yyyy/MM/dd" - format, if I want to keep the justification of a wrapping RuntimeException.

I didn't see any reference to ensureing that the customerID MUST be 8 digits (wouldn't less still work?)

Good question. Until now I have a validation:

because I thought that it should really contain 8 numbers. But perhaps you're right and 1 - 7 numbers are ok, too?
Other opinions?
Regards
Ulrich
 
Leo Tien
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stephen:
Of course a real "cop-out" solution is just to document that you'll leave it up to the systems administrator to remove any rooms that don't meet the 48hr criteria and then ignore it from then on

Have someone done it ?? Only document the 48hr criteria.
Hi Ulrich:
because I thought that it should really contain 8 numbers. But perhaps you're right and 1 - 7 numbers are ok, too?
Other opinions?

From my assignment " .....All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field. The character encoding is 8 bit US ASCII. "
Every field have a maximum length, not only owner. Read it you don't mind this, I do check only when write some data to the record. For example:
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Leo,
my input validation at the server side is similar to yours.

Regards
Ulrich
 
Leo Tien
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulrich:
....8-digit number..

I think since sun didn't require us to must do it, but In my design, I want to do it and also write it in my choices.txt. Because in the real word, digit-number ID commonly is equal length, e.g. the book digit mark(ISBN 7-5084-1055-6), telephone's number, post code and so on.
Comment ???
 
Leo Tien
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
May be the statement I said don't be worth commenting.
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Leo,
sorry to haven't answered you sooner.
I think since sun didn't require us to must do it, but In my design, I want to do it and also write it in my choices.txt. Because in the real word, digit-number ID commonly is equal length, e.g. the book digit mark(ISBN 7-5084-1055-6), telephone's number, post code and so on.

I think with your argumentation you should be sure to justify your decision. I will also keep my owner.matches("\\d{8}")-validation and I can't imagine Sun will take offence at it.
Greetings
Ulrich
 
Stephen Galbraith
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because in the real word, digit-number ID commonly is equal length, e.g. the book digit mark(ISBN 7-5084-1055-6), telephone's number, post code and so on.

Well, I think the key phrase is "normally". I mean a UK post code can be something list CV13 5TG or equally CV3 6UH, so these aren't equal length.
Bu then again in the instructions it does say you can make decesions as long as you justify them. I just think that you've possibly made up a rule that doesn't exist in the instructions.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Leo,
Since you have justified your decision you should be fine with what you have done. The important thing is always to justify design decisions.
As Stephen noted though, it is quite possible for there to be exceptions to "normal" rules which can cause unexpected problems later. Some standard examples: trying to fill in web pages which require a post code. In the States I believe than can vary between a 5 digit number and a 5-3 number (my memory is hazy on how many digits are in the second section). But you can still have troubles going to a web site that expects a minimum of 5 digits if you are coming from Australia (like I am) where we have 4 digit post codes. And many countries have letters in their post code. Until a few years back we had different length telephone numbers and area codes for city and country phone numbers.
Some time back Bill Robertson asked Sun whether a number less than 8 digits could be entered - their response is here.
Regards, Andrew
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
Originally posted by Andrew Monkhouse:
In the States I believe than can vary between a 5 digit number and a 5-3 number (my memory is hazy on how many digits are in the second section).

Just so it doesn't keep you awake at night , the newest US zip code is 9 digits total in the form xxxxx-xxxx. I think the full zip code is supposed to cover an area about the size of a city block. It's not required to be used on US mail (yet) and as you say many web sites only accept 5 digits anyway.
Hope this helps,
George
 
Leo Tien
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone:
I want to say "sorry" at first, I'm a chinese, in our country, the post code is absolute length: 6 digital. And the telephone I want to point is mobile number, it's absolute length too, 9 digital.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic