Problem with std::out_of_range

[Michael Hull]

Re: Problem with std::out_of_ran ge

On May 23, 6:26 am, Rolf Magnus <ramag...@t-online.dewrote:

James Kanze wrote:

On May 21, 8:08 pm, desktop <f...@sss.comwr ote:

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

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()?

[James Kanze]

Re: Problem with std::out_of_ran ge

On May 23, 6:26 am, Rolf Magnus <ramag...@t-online.dewrote:

James Kanze wrote:

On May 21, 8:08 pm, desktop <f...@sss.comwr ote:

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.

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()?

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 (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: Problem with std::out_of_ran ge

On May 22, 12:46 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

On 22 May, 05:01, Salt_Peter <pj_h...@yahoo. comwrote:

On May 21, 2:08 pm, desktop <f...@sss.comwr ote:

Salt_Peter wrote:
On May 21, 12:44 pm, desktop <f...@sss.comwr ote:
I have the following code:

#include <stdexcept>

int main(){

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

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

return 0;

}

but when I compile I get:

<various errors>
<snip>

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?

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.

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.

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.)

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.

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.

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.

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

Suppose the throw std::out_of_ran ge 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::out_of_ran ge 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.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34