some questions about Collections
[187 byte] By [valjok] at [2007-9-27 22:31:02] 
getItem(index or name): when to throw an exception when to return null?getIndex(Item): when to return -1 when exception?Is it better to have two versions of a method?
For both the cases dont throw exception. It shall not be in good form. Return null or -1 as expected - as this is a conventionally accepted behavior. Reserve exceptions for situations when your code cannot proceed any further.
However, what I told you is in good form but is not a "holy cow".
Ironluca
Ironluca at 2007-7-7 13:08:19 >
Ironluca, thanks you, it's exactly what I wanted to know. But In my case sometimes it can proceed further, sometimes it can't :o(. I would like to see any sources to better master the problem.
valjok at 2007-7-7 13:08:19 >
Well,
Allow me to explain the thing in a bit more detail. Let us take a container, whose primary function is to store a number of objects in a sequence (like a Vector). Now, when the client of the container calls the method - lets say getItem(int index), what should be the behaviour of the container. It is simple
1) If there exists an element at that index - the container should return the element.
2) If there are no elements at that index the container shall return "null".
The container shall not throw an excepton - because, by the method call nothing exceptional has occured inside the container, the container is still performing properly. It did not have the element in question, so it returned nothing - the container did not get into any trouble though!
To reiterate - in both the above cases dont throw exception. Look the problem from the perspective of the container. The application (if it did not get back any element from the container) is free to throw an exception - if the situation is an exception.
Ironluca
Ironluca at 2007-7-7 13:08:19 >
Suggested reading:
1.The Java Programming Language (Arnold, Gosling, Holmes) section 8.5 When to Use Exceptions, pages 206-207
compares reaching the end of input (expected behavior) and reading past the end of input (an unexpected error condition). discusses what is an unexpected error. discusses readable code and flow of control.
2. Core Java Volume 1 (Horstmann) chapter 11, section Some Tips on Using Exceptions, item #1 page 656
compares the time it takes to test the return value of the Stack.empty method with the time it takes to handle an EmptyStackException.
marlenemiller at 2007-7-7 13:08:19 >
> Well,
>
> Allow me to explain the thing in a bit more detail.
> Let us take a container, whose primary function is to
> store a number of objects in a sequence (like a
> Vector). Now, when the client of the container calls
> the method - lets say getItem(int index), what should
> be the behaviour of the container. It is simple
>
> 1) If there exists an element at that index - the
> container should return the element.
>
> 2) If there are no elements at that index the
> container shall return "null".
>
> The container shall not throw an excepton - because,
> by the method call nothing exceptional has occured
> inside the container, the container is still
> performing properly. It did not have the element in
> question, so it returned nothing - the container did
> not get into any trouble though!
What if I pass in -1 as the index?
What if there are 10 items and I pass in 100,000?
jschell at 2007-7-7 13:08:19 >
> What if I pass in -1 as the index?
>
> What if there are 10 items and I pass in 100,000?
-1 should throw an IllegalArgumentException
passing in an index greater than the size of the Collection could do one of two things (i) return the item at the last index
(ii) throw an OutOfBoundsException
My instinct would be to go for (ii)
Check out the JavaDoc for Sun's Collection API and see how they implement these conditions.
Regards,
Fintan
CelticPhantom at 2007-7-7 13:08:19 >
> What if I pass in -1 as the index?
>
> What if there are 10 items and I pass in 100,000?
jschell,
The choice to throw an exception or to return null is dependent on the application. If the container so feels that -1 or 10,000 shall impair its functionality or has impaired its functionality and it cannot recover from it - by all means, go ahead and throw your exception.
Vector is just an instance of a type of container - no body stops you from creating your own container and also in Vector - please notice that both are RuntimeException.
In the ultimate equation, it is the form that you chose that shall dictate wether you return null or throw an Exception. There is nothing absolute in this matter. My point was more subtle (to point to you, if you have failed to notice) - "Do not throw Excception, until you are sure that you cannot recover from the problem and proceed correctly".
Awaiting Comments
Ironluca
Ironluca at 2007-7-7 13:08:19 >
> > What if I pass in -1 as the index?
> >
> > What if there are 10 items and I pass in 100,000?
>
> jschell,
>
> The choice to throw an exception or to return null is
> dependent on the application. If the container so
> feels that -1 or 10,000 shall impair its functionality
> or has impaired its functionality and it cannot
> recover from it - by all means, go ahead and throw
> your exception.
Certainly. But the question wasn't addressing a specific application but rather a single component.
Given that my presumption would be to write the component based on the standpoint of a library and not an application.
That means that the component must make a decision based on correctness for the component, which is obvious since it can't do it based on correctness of the application.
This would suggest that if a index is passed in that exceeds the boundaries of the collection that throwing an exception is the correct decision. Because it exceeds the correctness of the average collection. Naturally that might not be true for a specific kind of collection, but the question wasn't addressing a specific kind of collection.
>
> Vector is just an instance of a type of container - no
> body stops you from creating your own container and
> also in Vector - please notice that both are
> RuntimeException.
>
Yes Vector uses a unchecked exception for boundary problems. Which one could take to suggest that in the general case that is a good idea.
> In the ultimate equation, it is the form that you
> chose that shall dictate wether you return null or
> throw an Exception. There is nothing absolute in this
> matter. My point was more subtle (to point to you, if
> you have failed to notice) - "Do not throw Excception,
> until you are sure that you cannot recover from the
> problem and proceed correctly".
I agree there are no absolutes. But I also think that when boundary conditions are exceeded in libraries then exceptions should be used most of the time. I believe most third party libraries take this stance. As an alternative sometimes they also provide a checked and unchecked versions which allows the user to decide the best recourse.
jschell at 2007-7-7 13:08:19 >
> I agree there are no absolutes. But I also think that
> when boundary conditions are exceeded in libraries
> then exceptions should be used most of the time. I
> believe most third party libraries take this stance.
> As an alternative sometimes they also provide a
> checked and unchecked versions which allows the user
> to decide the best recourse.
jschell
I am not fundamentally in disagreement with your views. However, as you mentioned yourself - the best recource is at the discretion of the user. Therefore, if the collection is getting built (as you mentioned), it could offer both facilities.
Regards
Ironluca
Ironluca at 2007-7-7 13:08:19 >
Other Topics New Topic
Other Topics Hot Topic
Other Topics
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding