Throwing exceptions

[pleatofthepants]

I am supposed to throw some exceptions in myVector class but when I
impliment them I get an error saying

myVector.h:139: error: looser throw specifier for `myVector&
myVector:opFront(T&) [with T = int]'
myVector.h:17: error: overriding `containerInterface&
containerInterface:opFront(T&) throw (BADINDEX) [with T = int]'

What is wrong with the way that I am throwing my exceptions in my
functions in the myVector class?
here is the .h

#ifndef _MYVECTOR
#define _MYVECTOR

using namespace std;



class BADINDEX {};

template <class T>
class containerInterface
{
public:

virtual containerInterface <T>& pushFront(T) = 0;
virtual containerInterface <T>& pushBack(T) = 0;
virtual containerInterface <T>& popFront(T&) throw (BADINDEX) = 0;
virtual containerInterface <T>& popBack(T&) throw (BADINDEX) = 0;
virtual int getSize() = 0;
virtual bool isFull() = 0;
virtual bool isEmpty() = 0;
virtual T front() throw (BADINDEX) = 0;
virtual T back() throw (BADINDEX) = 0;
virtual T& operator [] (int) throw (BADINDEX) = 0;
virtual void erase() = 0;

};

template <class T>
class myVector: public containerInterface<T>
{
private:

T *data;
int size;
int capacity;

void grow()
{
T *temp;
temp = data;
capacity *= 2;
data = new T[capacity];

for(int i = 0; i < size; i++)
{
data = temp;
}
delete [] temp;
}

void shiftRight()
{
//decrement this iteration
for (int i = size; i >= 0; i--)
{
data = data[i - 1];
}
size++;
}
void shiftLeft ()
{
for (int i = 0; i < size; i++)
{
data = data[i + 1];
}
size--;
}

public:

myVector ()
{
size = 0;
capacity = 10;
data = new T[capacity];
}

~myVector ()
{
delete [] data;
}
myVector (const myVector& v)
{
size = v.size;
capacity = v.capacity;
data = new T[capacity];
for (int i = 0; i < size; i++)
{
data = v.data;
}
}

myVector <T>& operator = (myVector& n)
{
delete [] data;

size = n.size;
capacity = n.capacity;

data = new T[capacity];

for (int i = 0; i < size; i++)
{
data = n.data;
}
return *this;
}

myVector <T>& pushFront(T e)
{
if (size == capacity)
{
grow();
}


shiftRight();

data[0] = e;
return *this;
}

myVector <T>& pushBack (T e)
{
if (size == capacity)
{
grow();
}



data[size] = e;
size++;
return *this;
}

myVector <T>& popFront (T& n)
{
if(isEmpty())
{
throw (BADINDEX());
}
n = data[0];
shiftLeft();


return *this;
}

myVector <T>& popBack (T& n)
{
if(isEmpty())
{
throw (BADINDEX());
}
n = data[size - 1];
size--;

return *this;
}

T front()
{
if(isEmpty())
{
throw (BADINDEX());
}
return data[0];
}

T back ()
{
if(isEmpty())
{
throw (BADINDEX());
}
return data[size - 1];
}

T& operator [] (int n)
{
if ( n >= capacity || n < 0 )
{
throw (BADINDEX());
}
return data[n];
}

int getSize()
{
return size;
}

bool isFull()
{
bool status;

if (capacity == size)
{
status = true;
}

else
{
status = false;
}
return status;
}

bool isEmpty()
{
bool status;

if (size == 0)
{
status = true;
}

else
{
status = false;
}
return status;
}
void erase()
{
size = 0;
}
};



#endif

 

[Victor Bazarov]

I am supposed to throw some exceptions in myVector class but when I
impliment them I get an error saying

myVector.h:139: error: looser throw specifier for `myVector&
myVector:opFront(T&) [with T = int]'
myVector.h:17: error: overriding `containerInterface&
containerInterface:opFront(T&) throw (BADINDEX) [with T = int]'

What is wrong with the way that I am throwing my exceptions in my
functions in the myVector class?

I think it's because the base class does have exception specifications
on a bunch of functions and the derived class doesn't.

here is the .h

#ifndef _MYVECTOR
#define _MYVECTOR

using namespace std;



class BADINDEX {};

template <class T>
class containerInterface
{
public:

[..]
virtual containerInterface <T>& popFront(T&) throw (BADINDEX) = 0;

^^^^^^^^ !!!!!

[..]
};

template <class T>
class myVector: public containerInterface<T>
{
[..]
myVector <T>& popFront (T& n)

^^^^^ ?????

{
if(isEmpty())
{
throw (BADINDEX());
}
n = data[0];
shiftLeft();


return *this;
}
[..]
};



#endif

V

 

[Ian Collins]

I am supposed to throw some exceptions in myVector class but when I
impliment them I get an error saying

myVector.h:139: error: looser throw specifier for `myVector&
myVector:opFront(T&) [with T = int]'
myVector.h:17: error: overriding `containerInterface&
containerInterface:opFront(T&) throw (BADINDEX) [with T = int]'

What is wrong with the way that I am throwing my exceptions in my
functions in the myVector class?

I think it's because the base class does have exception specifications
on a bunch of functions and the derived class doesn't.

Yet another reason not to use them!

 

[Andrey Tarasevich]

I am supposed to throw some exceptions in myVector class but when I
impliment them I get an error saying

myVector.h:139: error: looser throw specifier for `myVector&
myVector:opFront(T&) [with T = int]'
myVector.h:17: error: overriding `containerInterface&
containerInterface:opFront(T&) throw (BADINDEX) [with T = int]'

What is wrong with the way that I am throwing my exceptions in my
functions in the myVector class?

It has nothing to do with how you _throw_ your exceptions. The problem
is with exception specification of your function. In C++ derived class's
virtual function cannot widen the exception specification of the
corresponding virtual function in base class. You violated this
requirement, which is the reason for the error.

Here's the declaration of the base class's function

virtual containerInterface <T>& popFront(T&) throw (BADINDEX) = 0;

Note the exception specification 'throw (BADINDEX)', which means that it
is only allowed to throw 'BADINDEX' exceptions.

Here's the declaration of the derived class's function

myVector <T>& popFront (T& n)

Here you don't have any exception specification at all, which means that
this function is allowed to throw anything.

Obviously, the derived class's 'popFront' has wider exception
specification than base class's 'popFront', which is illegal in C++.

Declare your 'popFront' as

myVector <T>& popFront (T& n) throw (BADINDEX)

and that should fix the error.

 

[Andy Champ]

Yet another reason not to use them!

Funny that. I work in the MS compiler, which doesn't implement
exception specifications. So we have to hand document and check all the
exceptions, which is a right PITA - especially when you add a new
exception to some widely used worker function that's called from
half-a-dozen other functions which are then...

Andy

 

[Andrey Tarasevich]

Funny that. I work in the MS compiler, which doesn't implement
exception specifications. So we have to hand document and check all the
exceptions, which is a right PITA - especially when you add a new
exception to some widely used worker function that's called from
half-a-dozen other functions which are then...

MS compiler does implement [partial] support for one particular form of
exception specification that is often considered to be quite useful:
throw() (i.e. "no exceptions allowed").

The sad part though is that MS fails to enforce the compile-time
requirements imposed on exception specification (namely the one in the
OP's code), which sometimes leads to annoying surprises in
multi-platform development.

 

[Ian Collins]

Funny that. I work in the MS compiler, which doesn't implement
exception specifications. So we have to hand document and check all the
exceptions, which is a right PITA - especially when you add a new
exception to some widely used worker function that's called from
half-a-dozen other functions which are then...

Not as big a pain as going though adding all the exception
specifications and tracing the unhandled exception errors!

 

[James Kanze]

I am supposed to throw some exceptions in myVector class but when I
impliment them I get an error saying
myVector.h:139: error: looser throw specifier for `myVector&
myVector:opFront(T&) [with T = int]'
myVector.h:17: error: overriding `containerInterface&
containerInterface:opFront(T&) throw (BADINDEX) [with T = int]'
What is wrong with the way that I am throwing my exceptions
in my functions in the myVector class?

I think it's because the base class does have exception
specifications on a bunch of functions and the derived class
doesn't.

Yet another reason not to use them!

Or to use them systematically. If the contract established
by the base class guarantees no exceptions, the function in the
derived class had better not throw any either. (In practice,
the guarantees provided by an exception specifier are such that
they really only make sense for the nothrow guarantee.)

 

[James Kanze]

Ian Collins wrote:

Funny that. I work in the MS compiler, which doesn't
implement exception specifications. So we have to hand
document and check all the exceptions, which is a right PITA -
especially when you add a new exception to some widely used
worker function that's called from half-a-dozen other
functions which are then...

But you really have to do that anyway, if you're serious about
using them. The exception specification is actually a negative
guarantee---it guarantees that you won't see any exceptions not
listed. But it doesn't guarantee that you will see a specific
type of exception when a specific error condition occurs: that
has to be done by hand, with comments, code review and unit
tests.

 

[Andy Champ]

But you really have to do that anyway, if you're serious about
using them. The exception specification is actually a negative
guarantee---it guarantees that you won't see any exceptions not
listed. But it doesn't guarantee that you will see a specific
type of exception when a specific error condition occurs: that
has to be done by hand, with comments, code review and unit
tests.

What I'd like the compiler to do would be to complain if I threw an
unlisted exception, or called a function that threw one. The exceptions
could then be a part of the published contract, and allow users of the
functions to know what to expect.

However, I live in the real world. Koenig was right the other day, when
he said "The people with the gold make the rules".

Andy

(and where did that quote come from?)

 

[James Kanze]

What I'd like the compiler to do would be to complain if I
threw an unlisted exception, or called a function that threw
one. The exceptions could then be a part of the published
contract, and allow users of the functions to know what to
expect.

But it doesn't work like that. The fact that an exception is
listed in the exception specification doesn't mean that it will
ever be thrown. And of course, knowing to "expect" a particular
exception doesn't really buy you much; you have to know when to
expect it (e.g. the function couldn't open a file, etc.). (Most
of the time, of course, when you know you have to expect a
certain exceptional condition, a return value is a better choice
than exceptions. But there are exceptions, such as in
constructors, where even if a return value were possible, not
using an exception would result in a zombie object, which is
generally worse than having to use a try block rather than
simply test a return code.)

What an exception specification does is promess, as part of the
contract, that there will be no other exceptions. And the only
time I've found this useful is when the guarantee is that there
will be NO exceptions.

And of course, if the compiler sees that you might throw an
exception, but there is an exception specify that doesn't allow
it, it can (and probably should) warn. Making this recursive,
by requiring the compiler to take into consideration the
exception specifications of the functions your function calls,
can't really be made to work, however, for reasons of backwards
compatibility and compatibility with C. (Not to mention
problems with templates.)