This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
This is my situation: I thought when I did an ArrayList.add(ErrorObject) I was passing a COPY of the ErrorObject and that COPY of the ErrorObject was preserved no matter what happened to the �source� ErrorObject.
This doesn't appear to be the case...
Below is a drawn out description of what I'm experiencing � in case you need more details of my situation.
I designed a result object that I use when making calls. Almost all of my methods have a return value of ResultObject.
Example call: roResult = member.addMember("chris","montgomery");
This result object (roResult) has a few boolean members: protected boolean isSuccessful, hasErrors...
It also has a few string members: protected String methodName,className,packageName,responseString;
Lastly, it has two array list members: protected ArrayList errorArrayList, responseArrayList;
This way I can have a clear view of who, what, where, when and why each time a method call is made.
During the execution of addMember, if I stumble upon an error, I have yet another object - this time it's an ErrorObject (eoError) that I fill with what caused the error: eoError.fillErrorObject("stuff",�more stuff�,�even more stuff�, etc.);
(ErrorObject is a class with the following members: protected String errorNumber,errorDescription,errorPackageOccurnace,errorClassOccurnace,errorMethodOccurnace,externalErrorCode
Once this ErrorObject is filled, I do an addMemberErrorArrayList.add(ErrorObject);.
For each error I stumble upon in the addMember code, I clear and fill the ErrorObject and then make another addMemberErrorArrayList.add(ErrorObject) call.
Once I�ve gone gone through as much as I can, I set my ResultObject�s errorArrayList equal to my addMemberErrorArrayList that was built during the execution of addMember and return roResult.
The goal is to store ALL the errors I encountered during the call in my array list (so the user is fully informed rather than displaying one error at a time).
What I'm finding is that if I have 5 errors, my array list has 5 items in it, but they all contain the LAST error encountered (rather than the 5 individual errors):
Result Package: com.aid.core.data.process Result Class: ProcessMemberData Result Successful: true Result Has Errors: true ERROR COUNT: 1 OF 5 ERROR NUMBER: 11 ERROR DESCRIPTION: Email address is null. ERROR COUNT: 2 OF 5 ERROR NUMBER: 11 ERROR DESCRIPTION: Email address is null. ERROR COUNT: 3 OF 5 ERROR NUMBER: 11 ERROR DESCRIPTION: Email address is null. ERROR COUNT: 4 OF 5 ERROR NUMBER: 11 ERROR DESCRIPTION: Email address is null. ERROR COUNT: 5 OF 5 ERROR NUMBER: 11 ERROR DESCRIPTION: Email address is null.
I guess I thought when I did an ArrayList.add() I was passing a COPY of the ErrorObject and that COPY of the ErrorObject was preserved no matter what happened to the �source�.
Do I really have to instantiate a new ErrorObject every time I hit an error?
Based on what you posted, a new error object is exactly what you want. I understand that you think this might involve too much overhead but consider this: If Java passed everything by copy, you'd be instantiating a new object anyway. You would have to create a new object and fill it with the values that you were looking for, then add it to your data structure and the JVM would enforce this. Passing by reference (as default) is the more efficient approach, you can create many handles to one object and at your convienience, create copies.
Good luck. [ August 08, 2005: Message edited by: Jon Cone ]
Joined: Jan 14, 2004
Cool - thanks!
when I'm doing an ArrayList.add(), I'm not really passing anything by reference or value. I'm simply adding THE object.
Well, I guess that's exactly what passing by value is, but I'm also guessing I shouldn't think of it in these terms when populating collections.
Java has a simple consistent argument passing mechanism so regardless of the objects involved you can always think of them the same way. Java has objects, references and primitives. You never access objects directly; objects can be accessed only through a reference. Objects are not passed in to methods or returned from methods, rather, object references are.
The reference "points" to an object on the heap. It's like an address that contains the coordinates of the object withing the heap. The object doesn't move and it's not passed to or returned from anything, ever.
[ August 08, 2005: Message edited by: Rick O'Shay ]
[ August 08, 2005: Message edited by: Rick O'Shay ] [ August 08, 2005: Message edited by: Rick O'Shay ]