tags:

views:

37

answers:

3

Hi,

assume you have a function that polls some kind of queue and blocks for a certain amount of time. If this time has passed without something showing up on the queue, some indication of the timeout should be delivered to the caller, otherwise the something that showed up should be returned.

Now you could write something like:

class Queue
{
    Thing GetThing();
}

and throw an exception in case of a timeout. Or you write

class Queue
{
    int GetThing(Thing& t);
}

and return an error code for success and timeout.

However, drawback of solution 1 is that the on a not so busy queue timeout is not an exceptional case, but rather common. And solution 2 uses return values for errors and ugly syntax, since you can end up with a Thing that contains nothing.

Is there another (smart) solution for that problem? What is the preferred solution in an object oriented environment?

A: 

Why not just return null from GetThing in your first solution, changing it to return a Thing *? It seems to fit the bill, at least from the information you've given so far.

Vinay Sajip
A: 

In the first, and second case, you can't do anything but throw an exception. When you return a Thing, or a Thing&, you don't have the option of not returning a Thing.

If you want to fail without using an exception then you need:

class Queue
{
  // Either something like this. GetThing retuns NULL on an error, 
  // GetError returns a specific error code
  Thing* GetThing();
  int GetError();
  // This kind of pattern is common. Return a result code
  // and set ppOut to a valid thing or NULL.
  int GetThing(Thing** ppOut);
};
Chris Becke
It rather depends whether Thing has value or identity semantics - if Thing were std::string or an int, then not mutating a reference to a value is exactly what operator>> does when reading from a stream reaches EOF
Pete Kirkham
A: 

I would use exceptions only when the error is serious enough to stop the execution of the application, or of any big-enough application's component. But I wouldn't use exceptions for common cases, after which we continue the normal execution or execute the same function again. This would be just using exceptions for flow control, which is wrong.

So, I suggest you to either use the second solution that you proposed, or to do the following:

class Queue
{
    bool GetThing(Thing& t); // true on success, false on failure
    string GetLastError(); 
};

Of course you can stick with an int for an error code, instead of a string for the full error message. Or even better, just define class Error and have GetLastError() return it.

Igor Oks