Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What you think about throwing an exception for not found in C++?

I know most people think that as a bad practice but when you are trying to make your class public interface only work with references, keeping pointers inside and only when necessary, I think there is no way to return something telling that the value you are looking doesn't exist in the container.

class list {
    public:
        value &get(type key);
};

Let's think that you don't want to have dangerous pointers being saw in the public interface of the class, how do you return a not found in this case, throwing an exception?

What is your approach to that? Do you return an empty value and check for the empty state of it? I actually use the throw approach but I introduce a checking method:

class list {
   public:
      bool exists(type key);
      value &get(type key);
};

So when I forget to check that the value exists first I get an exception, that is really an exception.

How would you do it?

like image 221
Edwin Jarvis Avatar asked Sep 27 '08 14:09

Edwin Jarvis


People also ask

What happens if an exception is thrown and not caught?

What happens if an exception is not caught? If an exception is not caught (with a catch block), the runtime system will abort the program (i.e. crash) and an exception message will print to the console.

Why would you want to throw an exception?

Exceptions should be used for exceptional situations outside of the normal logic of a program. In the example program an out of range value is likely to be fairly common and should be dealt with using normal if-else type logic.

What will happen if exception is thrown?

A function that "handles" that kind of exception catches it. In C++, when an exception is thrown, it cannot be ignored--there must be some kind of notification or termination of the program. If no user-provided exception handler is present, the compiler provides a default mechanism to terminate the program.

Is it good to throw exception?

The short answer is NO. You would throw an exception if the application can't continue executing with the bad data. In your example, the logic is to display an error message on the front end and Option 2 is the cleaner method for achieving this requirement.


1 Answers

Accessor?

The "iterator" idea proposed before me is interesting, but the real point of iterators is navigation through a container. Not as an simple accessor.

I agree with paercebal, an iterator is to iterate. I don't like the way STL does. But the idea of an accessor seems more appealing. So what we need? A container like class that feels like a boolean for testing but behaves like the original return type. That would be feasible with cast operators.

template <T> class Accessor {
    public:
        Accessor(): _value(NULL) 
        {}

        Accessor(T &value): _value(&value)
        {}

        operator T &() const
        {
            if (!_value)
               throw Exception("that is a problem and you made a mistake somewhere.");
            else
               return *_value;
        }

        operator bool () const
        {
            return _value != NULL;
        }

    private:
        T *_value;
};

Now, any foreseeable problem? An example usage:

Accessor <type> value = list.get(key);

if (value) {
   type &v = value;

   v.doSomething();
}
like image 145
Edwin Jarvis Avatar answered Oct 24 '22 01:10

Edwin Jarvis