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

J

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?
 
V

Victor Bazarov

John said:
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
 
C

Cy Edmunds

John Black said:
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.
 
A

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

John Black

Cy said:
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.

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 ?
 
V

Victor Bazarov

John said:
Cy Edmunds wrote:




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
 
A

Andrey Tarasevich

John said:
...
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.
 
J

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
 
X

Xenos

jive said:
?

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top