Problem with std::out_of_range

[desktop]

I have the following code:

#include <stdexcept>


int main(){

int i = 10;
int arr;
int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

}

but when I compile I get:

no matching function for call to ‘std:ut_of_range:ut_of_range()’
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:99:
note: candidates are: std:ut_of_range:ut_of_range(const std::string&)
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:97:
note: std:ut_of_range:ut_of_range(const
std:ut_of_range&)


why can't I use std:ut_of_range() in this manner?

 

[Alf P. Steinbach]

* desktop:

I have the following code:

#include <stdexcept>

int main(){

int i = 10;
int arr;

Not standard C++.

int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

Not necessary: main is special, check out the various special rules for
main.

}

but when I compile I get:

no matching function for call to ‘std:ut_of_range:ut_of_range()’
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:99:
note: candidates are: std:ut_of_range:ut_of_range(const std::string&)
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:97:
note: std:ut_of_range:ut_of_range(const
std:ut_of_range&)


why can't I use std:ut_of_range() in this manner?

The error messages tell you (1) there is no default constructor, the one
you attempted to use, (2) but there is a constructor taking std::string
argument, and (3) there is a copy constructor.

Why don't you just /read/ the error messages?

 

[Baltimore]

I have the following code:

#include <stdexcept>

int main(){

int i = 10;
int arr;
int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

}

but when I compile I get:

no matching function for call to 'std:ut_of_range:ut_of_range()'
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:99:
note: candidates are: std:ut_of_range:ut_of_range(const std::string&)
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:97:
note: std:ut_of_range:ut_of_range(const
std:ut_of_range&)

why can't I use std:ut_of_range() in this manner?

The static method std:ut_of_range doesn't exist without arguments,
but with a std::string to indicate a message to display when the
exception is thrown.
e.g. : terminate called after throwing an instance of
'std:ut_of_range'
what(): My message

 

[Rolf Magnus]

I have the following code:

#include <stdexcept>


int main(){

int i = 10;
int arr;
int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

}


why can't I use std:ut_of_range() in this manner?

Because there is

no matching function for call to ‘std:ut_of_range:ut_of_range()’

You should

 

[Salt_Peter]

I have the following code:

#include <stdexcept>

int main(){

int i = 10;
int arr;
int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

}

but when I compile I get:

no matching function for call to 'std:ut_of_range:ut_of_range()'
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:99:
note: candidates are: std:ut_of_range:ut_of_range(const std::string&)
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:97:
note: std:ut_of_range:ut_of_range(const
std:ut_of_range&)

why can't I use std:ut_of_range() in this manner?

First off, your logic is wrong since arr[10] doesn't exist either. If
you are going to use exceptions and not bother catching them, you are
waisting your time.

#include <iostream>
#include <stdexcept>

template< typename T, const size_t Size >
class Array
{
T m_array[Size];
public:
T& operator[](const size_t i)
{
if(i >= Size)
throw std:ut_of_range("index out of range.");
return m_array;
}
};

int main()
{
try {
Array< int, 10 > instance;
instance[10] = 99; // throws
}
catch (const std::exception& e)
{
std::cout << "Error: " << e.what();
std::cout << std::endl;
}
}

And instead of reinventing the wheel, why don't you use std::vector
and its at() member function?

 

[desktop]

I have the following code:

#include <stdexcept>

int main(){

int i = 10;
int arr;
int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

}

but when I compile I get:

no matching function for call to 'std:ut_of_range:ut_of_range()'
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:99:
note: candidates are: std:ut_of_range:ut_of_range(const std::string&)
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:97:
note: std:ut_of_range:ut_of_range(const
std:ut_of_range&)

why can't I use std:ut_of_range() in this manner?

First off, your logic is wrong since arr[10] doesn't exist either.

What do you mean? Is it not just a a regular int array with 10 integers?


If

you are going to use exceptions and not bother catching them, you are
waisting your time.

Well does that not depend on what you want?

If I use a try/catch its because I want the program to continue after
the exception has been thrown. But sometimes I just want the program to
terminate and therefore I avoid using try/catch and just use a throw
statement.

 

[Marcus Kwok]

I have the following code:

#include <stdexcept>

int main(){

int i = 10;
int arr;
int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

}

First off, your logic is wrong since arr[10] doesn't exist either.

What do you mean? Is it not just a a regular int array with 10 integers?

arr has 10 elements, but the indices go from arr[0] to arr[9].
Therefore, arr[10] does not exist. In your code, if index == 10, then
it will try to assign to arr[10], which is an error.

 

[Alf P. Steinbach]

* Marcus Kwok:

I have the following code:

#include <stdexcept>

int main(){

int i = 10;
int arr;
int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

}
First off, your logic is wrong since arr[10] doesn't exist either.

What do you mean? Is it not just a a regular int array with 10 integers?

arr has 10 elements, but the indices go from arr[0] to arr[9].
Therefore, arr[10] does not exist. In your code, if index == 10, then
it will try to assign to arr[10], which is an error.

arr doesn't have 10 elements in standard C++.

It doesn't exist.

 

[BobR]

I have the following code:

#include <stdexcept>
int main(){

// > int i = 10;

int const i( 10 );

int arr;
int index = 11;

if (index > i) {

// > throw std:ut_of_range();

std::string msg( "out of range error in main()" );
throw std:ut_of_range( msg );

}
else {
arr[index] = 33;
}

return 0;
}

but when I compile I get:

why can't I use std:ut_of_range() in this manner?

Why would you want to? Where are you going to 'catch' it?
Why not 'throw std::terminate();' or 'return EXIT_FAILURE;' ?

 

[Pete Becker]

std::string msg( "out of range error in main()" );
throw std:ut_of_range( msg );

Simpler:

throw std:ut_of_range("out of range error in main()");

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Marcus Kwok]

* Marcus Kwok:

Salt_Peter wrote:
I have the following code:

#include <stdexcept>

int main(){

int i = 10;
int arr;
int index = 11;

if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}

return 0;

}
First off, your logic is wrong since arr[10] doesn't exist either.
What do you mean? Is it not just a a regular int array with 10 integers?

arr has 10 elements, but the indices go from arr[0] to arr[9].
Therefore, arr[10] does not exist. In your code, if index == 10, then
it will try to assign to arr[10], which is an error.

arr doesn't have 10 elements in standard C++.

It doesn't exist.

Oh, right, I overlooked that i was not const, which you had already
pointed out in a previous post, but then I got distracted by the
indexing problem

 

[Salt_Peter]

I have the following code:
#include <stdexcept>
int main(){
int i = 10;
int arr;
int index = 11;
if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}
return 0;
}
but when I compile I get:
no matching function for call to 'std:ut_of_range:ut_of_range()'
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:99:
note: candidates are: std:ut_of_range:ut_of_range(const std::string&)
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/stdexcept:97:
note: std:ut_of_range:ut_of_range(const
std:ut_of_range&)
why can't I use std:ut_of_range() in this manner?

First off, your logic is wrong since arr[10] doesn't exist either.

What do you mean? Is it not just a a regular int array with 10 integers?

It would be if the array's size is const.
An array with 10 elements runs from 0 to 9.
There is no arr[10].

Think:
arr[0] arr + 0 is first element (think offset)
arr[1] arr + 1 is second element
....
arr[9] arr + 9 is tenth element

C++ doesn't do like in VB where an array of 10 elements has 11
elements but the first one at array[0] is left unused. Whoever thought
that up was brain-dead and didn't know how to count.

If


Well does that not depend on what you want?

If I use a try/catch its because I want the program to continue after
the exception has been thrown. But sometimes I just want the program to
terminate and therefore I avoid using try/catch and just use a throw
statement.

Thats illogical. You are forcing the program to commit an unhandled
exception.
Lets face it, how where you planning to figure out that an
out_of_range exception was indeed thrown? Specially since you seem to
indicate that arr[10] exists (it doesn't)?
The point here is that you are throwing an out_of_range exception, are
you not?
Why are you splitting your brain to throw a particular type of
exception and then not bother catching it for feedback?
Why not return or terminate instead? Or throw an integer?

 

[James Kanze]

Salt_Peter wrote:

[...]

Well does that not depend on what you want?

If I use a try/catch its because I want the program to continue after
the exception has been thrown. But sometimes I just want the program to
terminate and therefore I avoid using try/catch and just use a throw
statement.

In which case, abort() (or assert(0), to get line number and
file name) is generally better. When the program aborts because
of an uncaught exception, it's undefined whether the stack has
been unwound and the context lost or not.

 

[Nick Keighley]

I have the following code:
#include <stdexcept>
int main(){
int i = 10;
int arr;
int index = 11;
if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}
return 0;
}
but when I compile I get:

<various errors>

well, I'm not an experienced C++ user, but I do sometimes throw
exceptions that arn't caught...

Thats illogical. You are forcing the program to commit an unhandled
exception.

so? Is that wrong?

Lets face it, how where you planning to figure out that an
out_of_range exception was indeed thrown? Specially since you seem to
indicate that arr[10] exists (it doesn't)?
The point here is that you are throwing an out_of_range exception, are
you not?

and the program can't handle it, so it terminates. So?

Why are you splitting your brain to throw a particular type of
exception and then not bother catching it for feedback?
Why not return or terminate instead?

if you terminates then the destructors don't get called.
In a larger program that might clean up and release resources
that are important. Returning means the program is running in an
inconsistant state.

Or throw an integer?

Effective C++ (or one of its children) recomends that all exceptions
are derived from std::exception. I have a project that has six (six!)
different exception base classes. This is a pain.

Suppose the throw std:ut_of_range was in a library. The original
client cannot handle out of range (eg. Ariane-4 ). A later
client must handle the exception (call it Ariane-5 for example)
but cannot recompile the library. Now std:ut_of_range makes sense.

Normally I catch exceptions in main() so at least it reports the
exception before it terminates. But all the destructors get called
first.

 

[Rolf Magnus]

Salt_Peter wrote:
[...]

If
you are going to use exceptions and not bother catching them, you are
waisting your time.

Well does that not depend on what you want?

If I use a try/catch its because I want the program to continue after
the exception has been thrown. But sometimes I just want the program to
terminate and therefore I avoid using try/catch and just use a throw
statement.

In which case, abort() (or assert(0), to get line number and
file name) is generally better.

I get a full backtrace from unhandled exceptions.

When the program aborts because of an uncaught exception, it's undefined
whether the stack has been unwound and the context lost or not.

And that's different for abort()?

 

[Michael Hull]

Salt_Peter wrote:

[...]
If
you are going to use exceptions and not bother catching them, you are
waisting your time.
Well does that not depend on what you want?
If I use a try/catch its because I want the program to continue after
the exception has been thrown. But sometimes I just want the program to
terminate and therefore I avoid using try/catch and just use a throw
statement.

In which case, abort() (or assert(0), to get line number and
file name) is generally better.

I get a full backtrace from unhandled exceptions.

Sorry, I know its OT, but out of interest from which compiler??
Thanks
Mike

 

[James Kanze]

Salt_Peter wrote:

[...]

If
you are going to use exceptions and not bother catching them, you are
waisting your time.
Well does that not depend on what you want?
If I use a try/catch its because I want the program to continue after
the exception has been thrown. But sometimes I just want the program to
terminate and therefore I avoid using try/catch and just use a throw
statement.

In which case, abort() (or assert(0), to get line number and
file name) is generally better.

I get a full backtrace from unhandled exceptions.

It depends on the compiler. It's undefined whether the stack is
unwound or not.

And that's different for abort()?

Good point. Under Unix, you do, but I think that it does depend
on the system. (You can get something similar under
Windows---at least the developers here do. On the other hand,
on an embedded system, without a disk?) But the language
doesn't authorize unwinding of the stack in the case of abort,
so you're at least guaranteed that the destructors aren't
called.

 

[James Kanze]

Salt_Peter wrote:
I have the following code:
#include <stdexcept>
int main(){
int i = 10;
int arr;
int index = 11;
if (index > i) {
throw std:ut_of_range();
}
else {
arr[index] = 33;
}
return 0;
}
but when I compile I get:

<various errors>
<snip>

well, I'm not an experienced C++ user, but I do sometimes throw
exceptions that arn't caught...

It happens even to experienced programmers from time to time.
Especially if you're using a library which doesn't document the
exceptions it throws, or even that it throws exceptions.

so? Is that wrong?

Generally, yes. It's not something you would do intentionally
in production code.

Lets face it, how where you planning to figure out that an
out_of_range exception was indeed thrown? Specially since you seem to
indicate that arr[10] exists (it doesn't)?
The point here is that you are throwing an out_of_range exception, are
you not?

and the program can't handle it, so it terminates. So?

It might clean up the stack before terminating. Executing code
in the destructors. If you've found an error in the code, you
don't want that. (And if the exception isn't an error, you
certainly want to catch it.)

if you terminates then the destructors don't get called.
In a larger program that might clean up and release resources
that are important.

Or anything else, given that you've found an error---a program
state which shouldn't be possible. It's dangerous to execute
code if you're not sure of the program state; it's better to
terminate the program as quickly as possible, so that it doesn't
do any more damage.

Returning means the program is running in an
inconsistant state.

Calling abort() means that the program isn't running at all.
Once the state has been detected to be inconsistant, there's no
way to restore consistancy.

Effective C++ (or one of its children) recomends that all exceptions
are derived from std::exception. I have a project that has six (six!)
different exception base classes. This is a pain.

It's a good recommendation. Historically, however... a lot of
code was written before libraries supported std::exception.

Suppose the throw std:ut_of_range was in a library. The original
client cannot handle out of range (eg. Ariane-4 ). A later
client must handle the exception (call it Ariane-5 for example)
but cannot recompile the library. Now std:ut_of_range makes sense.

Just a nit, but the software for Ariane did throw an exception.
In fact, the software behaved exactly as it was supposed to.
The error was using it where it wasn't designed to be used:
complaining about the software here is about like complaining
that your Ada compiler gives you all sorts of errors when you
use it to compiler your C++.

Normally I catch exceptions in main() so at least it reports the
exception before it terminates. But all the destructors get called
first.

Which in case of an error is exactly what you want to avoid.