why catch (...) can not catch such exception

[John Black]

Hi,
I have a code like this structure,

try{
.. some function call...
}
catch (...){
return NULL;
}

during those function calls, the code has a bug which calls STL
vector erase() to delete a NULL pointer, but the problem is catch(...)
does not catch the error, instead I get a segment fault.

What is the problem?

[Victor Bazarov]

John Black wrote:

I have a code like this structure,

try{
.. some function call...
}
catch (...){
return NULL;
}

during those function calls, the code has a bug which calls STL
vector erase() to delete a NULL pointer, but the problem is catch(...)
does not catch the error, instead I get a segment fault.

What is the problem?

Hard to say. 'delete'ing a NULL pointer is explicitly allowed and
is a NOP. Could it be that it's calling a member function using
a pointer that is NULL, thus dereferencing it? That's not allowed.
Exceptions produced by the execution environment do not always fall
into C++ "catchable" category. Ask in the newsgroup for your OS or
your compiler to see if there is a compiler- or platform-specific
solution.

Victor

[Cy Edmunds]

"John Black" <bl***@eed.com> wrote in message
news:41**************@eed.com...

Hi,
I have a code like this structure,

try{
.. some function call...
}
catch (...){
return NULL;
}

during those function calls, the code has a bug which calls STL
vector erase() to delete a NULL pointer, but the problem is catch(...)
does not catch the error, instead I get a segment fault.

What is the problem?

As Victor said, deleting a NULL pointer is not an error. There are many
programming errors in C++ which result in the dreaded "undefined behavior".
In such cases there is NO guarantee that an exception will be thrown. In
fact there are no guarantees of any kind, hence the term.

--
Cy
http://home.rochester.rr.com/cyhome/

[Alf P. Steinbach]

* John Black:

Hi,
I have a code like this structure,

try{
.. some function call...
}
catch (...){
return NULL;
}

during those function calls, the code has a bug which calls STL
vector erase() to delete a NULL pointer, but the problem is catch(...)
does not catch the error
'catch' does not catch errors, it catches exceptions.

§23.1/10: "no erase() ... function throws an exception".

instead I get a segment fault.

What is the problem?

That you call erase with a NULL pointer instead of a valid iterator.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[John Black]

Cy Edmunds wrote:

"John Black" <bl***@eed.com> wrote in message
news:41**************@eed.com...

Hi,
I have a code like this structure,

try{
.. some function call...
}
catch (...){
return NULL;
}

during those function calls, the code has a bug which calls STL
vector erase() to delete a NULL pointer, but the problem is catch(...)
does not catch the error, instead I get a segment fault.

What is the problem?

As Victor said, deleting a NULL pointer is not an error. There are many
programming errors in C++ which result in the dreaded "undefined behavior".
In such cases there is NO guarantee that an exception will be thrown. In
fact there are no guarantees of any kind, hence the term.

--
Cy
http://home.rochester.rr.com/cyhome/

that's a little scary to know this...I had relied heavily on catch (...) to
prevent my software from crash...is there any way to better handle error ?

[Victor Bazarov]

John Black wrote:

Cy Edmunds wrote:

"John Black" <bl***@eed.com> wrote in message
news:41**************@eed.com...

Hi,
I have a code like this structure,

try{
.. some function call...
}
catch (...){
return NULL;
}

during those function calls, the code has a bug which calls STL
vector erase() to delete a NULL pointer, but the problem is catch(...)
does not catch the error, instead I get a segment fault.

What is the problem?

As Victor said, deleting a NULL pointer is not an error. There are many
programming errors in C++ which result in the dreaded "undefined behavior".
In such cases there is NO guarantee that an exception will be thrown. In
fact there are no guarantees of any kind, hence the term.

--
Cy
http://home.rochester.rr.com/cyhome/

that's a little scary to know this...I had relied heavily on catch (...) to
prevent my software from crash...is there any way to better handle error ?

Certain errors can only be handled by OS-specific means. Please ask in
a newsgroup dedicated to your OS for more information.

V

[Andrey Tarasevich]

John Black wrote:

...
I have a code like this structure,

try{
.. some function call...
}
catch (...){
return NULL;
}

during those function calls, the code has a bug which calls STL
vector erase() to delete a NULL pointer, but the problem is catch(...)
does not catch the error, instead I get a segment fault.
...

'catch' does not catch "errors". It catches C++ exceptions thrown by
'throw'. If you program crashes, 'catch' won't help you to prevent this.
Some implementations might provide certain facilities that allow you to
"convert" various hardware/OS-specific crash situations into C++
exceptions (manually or automatically), but it depends on the concrete
implementation, can be expensive and not always bulletproof.

--
Best regards,
Andrey Tarasevich

[jive]

> that's a little scary to know this...I had relied heavily on catch (...)
to

prevent my software from crash...is there any way to better handle error ?

If your software crashes, it's faulty and should be treated as one. This
sounds as an dangerous approach to program design.

jive

[Xenos]

"jive" <ji**@nospam.invalid> wrote in message
news:cg***********@news.cc.tut.fi...

that's a little scary to know this...I had relied heavily on catch (...) to

prevent my software from crash...is there any way to better handle error

?
If your software crashes, it's faulty and should be treated as one. This
sounds as an dangerous approach to program design.

jive

No, its not. It's called fault tolerant programming. Such a program should
*never* crash. It should detect such detrimental problems and handle them
accordingly. This "handling" can be anything appropriate for the design of
the systems, such as restarting the process or rebooting the system.
Usually when rebooting (which can be as quick as a few nanoseconds or take
several minutes), a backup computer takes over until the master is health
again. Before "fixing" the problem the system can save information on it in
persistent storage so it can be invested during post-mission analysis.

DrX