NX: handling of Remote- and ParseException

[Ulrich Heeger]

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:

bookButton.addActionListener(
           new ActionListener(){
                 public void actionPerformed (ActionEvent ae){ 
                  ...
            try{
             ....
                 }
                   catch (GUIException ge){
                    Throwable rootException = ge.getCause();
                    String msg = 
                                 "Failed to book this record.\n";
    ...
                           if(rootException instanceof RemoteException){
                     msg += "A remote exception occured.\n" +
                    "Check the connection to the rmi-server.";
               }
               ...
            
                       ApplicationStarter.handleException(msg);
                      }
            }   
 });

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:

private void validateDate(String date) 
              throws RecordBookException, ParseException{
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd");
          //may throw a ParseException:
Date formatedDate = dateFormat.parse(date);
         GregorianCalendar calendar = new GregorianCalendar();
Date actualFormDate = dateFormat.parse(
                                  calendar.get(Calendar.YEAR) +
     "/" + 
                                 (calendar.get(Calendar.MONTH) + 1) + 
     "/" + 
                                  calendar.get(Calendar.DAY_OF_MONTH));

//here the validating code to check the 48h criterium
// which may throw a RecordBookException
}

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]

Hi everyone,
Help me, please
Ulrich

[Stephen Galbraith]

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]

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:

private void validateCustomerID(String owner) 
                                 throws RecordBookException{
if(owner.equals("") || !(owner.matches("\\d{8}")))
throw new RecordBookException
         ("The customer ID has to be an eight digit number"); 
}

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]

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:

 length = thisFieldLength;
if value.length < length then valueStringBuffer.append(" ");//one number of blank.
else value = value.substring(0, length);
return value; 

[Ulrich Heeger]

Hi Leo,
my input validation at the server side is similar to yours.

 int destPos = 0;
       for(int j = 0; j < numFields ; j++){
    tempArray = new byte[fieldLength[j]]; 
    byte[] recData = null;
            recData = data[j].getBytes("US-ASCII"); 
            for (int i = 0; i < fieldLength[j]; i++){            
 if (i < recData.length)               
    tempArray[i] = (byte) recData[i];            
  else    
    tempArray[i] = (byte) ' ';            
     }
     System.arraycopy
                  (tempArray, 0, buffer, destPos, tempArray.length);  
     destPos += fieldLength[j];
} 

Regards
Ulrich

[Leo Tien]

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]

Hi all,
May be the statement I said don't be worth commenting.

[Ulrich Heeger]

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]

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]

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]

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]

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.