• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Update Method, Validation, RuntimeException

 
Markus He. Jung
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

i'm working on the URLyBird - specificaton 1.3.2.

The update Method is specified as:
// Modifies the fields of a record. The new value for field n
// appears in data[n].
public void update(int recNo, String [] data)
throws RecordNotFoundException;

in compare to the specification of the find method which is:
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public int [] find(String [] criteria)
throws RecordNotFoundException;

...
Question 1 (Array-Length):
==========================
can i assume that this means that there must be an array of 7 elements (number of fields).

I would prefer this.

Question 2 (Reasons for an error):
==================================
Since the specification of find says, fields with null values can be ignored and in the specification of update there is nothing stated about null values, is this a case of an error. Another case of an error is when i field that has the length of 8 has to be updated with a string that has the length of 10 and the last reason for an error is if there is specified that a field can only have the value Y and N and there comes another value.

Question 3 (Error handling):
============================
If a update is called for an record with an invalid record number, for example -1 or 100 (and the maximum record number is 99) or an deleted record than it is clear to throw an RecordNotFoundException.
But what about the errors mentioned in question 2. Should i truncate values that are too long? That could be one strategy. But what about invalid values, like A for the Y/N - field?

In the book of A. Monkhouse is mentioned to bypass this situation with a RuntimeException, since we cannot extend the interface. My solution would by to introduce a InvalidArgumentException that extends from RuntimeException.

Has anyone passed the exam with one of these solutions?

Thanks for your help.
Markus Jung
 
Rob van Oostveen
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Markus,

I will try to help you a bit with your decisions:


Question 1 (Array-Length):
==========================
can i assume that this means that there must be an array of 7 elements (number of fields).


Not sure what you mean exactly. But if you mean the criteria array in the find method.. the answer is in the header of you database file. The number of elements should be the same as the number of fields in a record. I cant tell if this should be 7 or not.


Question 2 (Reasons for an error):
==================================
Since the specification of find says, fields with null values can be ignored and in the specification of update there is nothing stated about null values, is this a case of an error.


Some parts of the assignment are deliberately not specified. My guess is that this is one them. Personally I'm working on the URLyBird 1.2.1 and the update method specifies that any null field can be ignored and doesn't need to be updated in the record.


Another case of an error is when i field that has the length of 8 has to be updated with a string that has the length of 10 and the last reason for an error is if there is specified that a field can only have the value Y and N and there comes another value.


Dont really understand your question here. But I choose to update a field with all characters which fit into the field and ignore all that dont fit. I'm not exiting the update method with an error when the number of characters exceed the field length. If Sun is not explicitly saying anything about this, then I suggest to implement it like you want it.


Question 3 (Error handling):
But what about invalid values, like A for the Y/N - field?
In the book of A. Monkhouse is mentioned to bypass this situation with a RuntimeException, since we cannot extend the interface. My solution would by to introduce a InvalidArgumentException that extends from RuntimeException.


I choose to ignore that in the database layer and implement content checking on a higher level (GUI?). I assume that content checking is already done whenever de update method is called.
When doing so, you dont have to worry about extending Exception classes or throwing runtime exception or anything else for that matter.

Regards,
Rob
 
Markus He. Jung
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply.

Some statements help me a lot.

Question 1 is now clear for me. There are 7 fields in my database scheme. My question was, is it possible that someone passes an array with only one element. For example to update only the first field.

Question 2 is also clear. I will allow null values and don't update the fields where in the passed array a null value exists. I think if i add this decision to my other documentation (decesions.txt) it will be clear.

Question 3 ...
Since we can only book a record (in my assignment), i have only a check in my GUI for the csr-id which is limited to 8 characters.

I'm a little bit scared about the automatic failure. I would make sense, that my assignment is first checked with an automated test tool (for example Junit Testcases) that check if my implementation of of DBMain.java is correct.

In the database scheme specification it is explicit mentioned that the allowed values for the field smoking are 'Y' and 'N', so it would make sense that if someone tries to update a record and set the smoking field to 'a' an exception is thrown.

There are two possible solution:
1. Like you did, write in your decisions file that every parameter has to be checked before it comes to the db-layer.
2. my preferred method is to raise an exception if illegal arguments come to the db-layer. Since IllegalArgumentException is a standard built-in exception for such cases, where dumb values are passed as parameters it would make sense to do so.

Has anyone passed the assignment with one of these solutions?

Greetings,
Markus Jung
 
Michael Creech
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm dealing with the same issues for B&S where the DataBase interface has a create() and update() method that take a 'String[] data' argument.

From other posts I've read, I believe the server-side database will be tested with some sort of test harness, independent of the GUI. I'm focused on what to do at the database API level, NOT the GUI.

I'm thinking of throwing an IllegalArgumentException if:

1) the 'data' parameter's array size is too small or too large.
2) The string value of a given array element is too large for its corresponding database field.

What I'm having problems deciding is:

a) If string value of a given array element is too small for corresponding database field, should this be an error or just pad it to fill in the field.

b) Should numeric fields be checked, such as the 'Size' and 'Rate' fields, and a IllegalArgumentException thrown, or should such checks be ignored for simplicity?

What are others doing for these cases?
----------------
SCJP1.4, SCJP1.5
 
Rob van Oostveen
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

About the IllegalArgumentException discussion.. in my assignment I had to stick to an interface contract supplied by Sun. So adding an exception in my case will change the interface contract which is not allowed. Don't you have an interface to implement? I doubt it cause I can imagine that Sun uses the predefined interface for their testing software...
Any additional exception is not caught in their testing software I guess. That's my opinion.

Good luck.

Rob
 
Michael Creech
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ya, there's an interface contract, but it doesn't explicitly cover data input errors. For example, the contract for create() is:



So my thinking is that there are only four possibilities when called with bad 'data' param:

1) Throw a DuplicateKeyException--this seems misleading and does not seem right for input errors in the 'data' parameter.

2) Throw a new checked exception, such as IllegalRecordArgumentException--this doesn't seem possible because we'd have to change our interface contract, which isn't allowed.

2) Create a blank, or partially filled record--this also seems wrong in that it could corrupt the database and there is probably a serious problem that would be propagated elsewhere, since the input is incorrect to the method.

3) Throw a unchecked exception, like IllegalArgumentException--this seems like the best alternative and is common practice. However, you do pose a good question about what Sun will expect when testing the Data implementation of the DB interface (for B&S).
 
Rodrigo W Bonatto
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Throw an unchecked exception and document it in your design choices and in source code.

Instead throwing an unchecked exception, you could treat the specific cases and also document it.

I think there is no better solution, but there is a bad solution: swallowing an exception and not documenting your decision.

It's my opinion.

Regards,

[ March 30, 2007: Message edited by: Rodrigo W Bonatto ]
[ March 30, 2007: Message edited by: Rodrigo W Bonatto ]
 
Rodrigo W Bonatto
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I apologize for the duplicated post.
[ March 30, 2007: Message edited by: Rodrigo W Bonatto ]
 
Ravikiran Vishnuvajhala
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marcus,

I am a bit confused about your question #1. Are you saying that we should throw an error if the input array size is smaller/larger the number of fields in the database?

I am not sure if it is true for the find method. What if I want to search for only one field in the database which is the fourth column in the database. Can I not create an array of size 4 elements and pass it to the find method and keep the values for the first three elements null?

What do others think?

Thanks
Ravi
 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ravi,

BTW: You can do a lot and Sun can decided it your design choice fits to their requirements.

I think as long as you/we/I describe why I choose a design decision and did go for a different way, Sun might agree with me. As far as I can see it, all our design decisions have to be reasonable/clear/common in the java community.

Because of the fact that we already know by our assignemtn how long a record should be, I assume that any input parameter of type that describes a record has the same length as the record has.
 
Markus He. Jung
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

thanks for your replies. I wouldn't assume that a String that is passed to a method of the Data class has exactly the correct size.

In URLyBird 1.3.2 the specification says: 'All text values, and all field .... null terminated if less than the maximum length of the field'.

BUT: The datafile looks different, there is everywhere a padding (spaces) that fill up the whole field.

My design desicion: if a value's length is less than the maximum length, it is filled up with a padding, but in my architecture a layer deeper in a
class FileAccess. This makes the new application compatible to the old running applications which are mentioned in the assignment.

I will try it with the unchecked exception approach. This seems to be the best solution since, it would not be nice to corrupt the datafile with invalid field values.

If someone has passed with an unchecked exception approach, please post it.

Thanks for the discussion,
Markus Jung
 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Markus,

I think we misunderstood each other. The array length of the input parameter should be the same length as the attributes of a record.

The length of each string value of the array can be less as stated in the database schema.

For example the database schema claims that there is an attribute name that has the length=6 the input parameter can be for example

  • fred
  • freddy
  • ravi
  • anna


  • I guess Sun wants to check if and how we handle if the input parameter is longer then the database schema allows like

  • Annette
  • Ravikiran
  •  
    Mihai Radulescu
    Ranch Hand
    Posts: 918
    IntelliJ IDE Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi people,

    I think that we have two different problem here:
    1.input validation
    2.how we react on malformed input.

    So in my opinion we need something a Validation Layer placed between the Data class and its file handler (the file handler is the class responsible for the physical database file access). The reason for a separate layer is the flexibility and a better class responsibility.
    So the Validation Layer can decide if the input is valid or not, and we can signal malformed input an exception - unfortunately with an RunTimeException(or with a checkable chained in to RTE) because we need to keep the interface from sun intact.

    We can extend this logic also on the client side.

    Regards M
     
    Erkin Kanlioglu
    Greenhorn
    Posts: 20
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi People

    Do we really think that Data layer will be tested with wrong data by using junit or another library ?

    wrong data can be identified as
    ridiculous array length as input of find or update or create method
    strange values in the input String array

    Honestly, In my solution, every control regarding input is in different layer(As talked previously). Data layer is only responsible for writing and readind etc from file. And I think that This is what Sun should expect
    from well layered application or basically MVC.

    Thanks
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic