Return error status to caller

[lizard43]

Hello -

What's a good way to return an error status to the caller of a utility method? I have a class that stores and retrieves objects. During the operations, several errors can occur. The team prefers that these methods do not throw exceptions, but instead return error codes somehow. Here's the current methods (names changed to protect idiots):

boolean storeObject(Object data);
Object getObject(SomeCriteria stuff);
Object[] getAllObjects();

Currently, storeObject returns false on fail, the others return null on fail. We want to return a meaningful status code so the caller can take appropriate action. Should we do something like this?

final SUCCESS=0;
final NOT_FOUND=1;
final DISK_FULL=2;
etc

short storeObject(Object data);
short getObject(SomeCriteria stuff, list objs);
short getAllObjects(list objs);

Problem with above is the caller will have to provide an empty list prior to calling. Some team members complain that this is a messy interface.

Also, it's possible that several different types of errors can occur on the getAll, (we have 1000 objs, 998 are good, 1 has bad data, 1 is invalid for another reason). So it was suggested:

short getAllObject(list obj, list errs);

Help! All advice is welcome.

Thanks,
lizard43

 

[idarke]

Advice: flog your "team" until they allow you to throw exceptions. It's the proper way to do it for several reasons:

1) It's the reason the exception mechanism exists.
2) It's extensible - you can add error conditions without changing any of the existing error handling - just add a new exception type and a new catch block to handle it.
3) It's flexible - the error can be handled directly by the caller or passed back up the heirarchy to higher methods to handle.

Passing back status codes is a hold-over from other languages, and it's a hard habit to break. But you'll be glad you did.

 

[lizard43]

Hi -

Thanks for your reply. I'm a new guy on the team, so I can't do much flogging.

Yes, I agree that exceptions are the way to go. But the main reason why a few people on the team don't want exceptions is because of getAllObjects().

We have 1000+ objects to return. If a few are bad, we still need to return the good ones. If we throw an exception, we stop processing. So what about this hack?:

void storeObject(Object obj) throws MyException;
Object getObject(SomeCriteria stuff) throws MyException;
Object[] getAllObjects();

The first two throw exceptions, where getAll will return an array of objects. Most of the array will be good objects, but a few will be exception objects. The processor of the array will have to do a instanceOf check on the objects.

Opinions please!

thanks,
lizard43

 

[idarke]

Yep, that would work. You could even have getAllObjects maintain a separate collection of exception objects caught, and provide a getExceptions method to pass the collection back for handling.

It sounds like errors are going to be the norm rather than the exception, otherwise I would have suggested keeping two collections with two getters (one for the successfully gotten objects and one for the exceptions), and have getAllObjects actually throw an exception at the end to indicate that at least one error occured. But it sounds like at least one exception is likely every time...