Chuck_McDevitt@a-t-t-b-i.com ("Chuck_McDevitt") wrote in message news:<AtYX9.11097$Ve4.1888@sccrnsc03>...
> If I have some code like this:
>
>   try {
>            somefunction();
>        }
>        catch(...)
>       {
>           //do something here
>       }
>
> What is standard behavior if somefunction() causes a
> system exception like seg fault or divide by zero?

catch only catches exceptions in the C++ sense of that word. In your
phrase "system exception" you are using the word 'exception' to mean
something other than a C++ exception. Things like seg fault and divide
by zero yield undefined behaviour (well, undefined by the C++ ISO std
anyway).

-apm

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

If we are talking about UNIX like OS-es then the following applies:
segfault does not cause an exception but a signal (SIGSEV) and the
signal handler is called (a default Linux system handles this by dumping
a core and exiting). I do not know what division by zero does.



Chuck_McDevitt wrote:
> If I have some code like this:
>
>   try {
>            somefunction();
>        }
>        catch(...)
>       {
>           //do something here
>       }
>
> What is standard behavior if somefunction() causes a
> system exception like seg fault or divide by zero?
>
> At first viewing, I would think catch(...) would catch any
> kind of exception, but there is an inconsistency, since
> even if somefunction is declared to not throw anything,
> it could still throw a seg fault or other system exception.
>
> Are exceptions other than those caused by "throw" just
> not part of the standard at all?
>
> Or can a compiler never optimize away a try catch even if
> the only code in the try is declared to never throw?
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

--
==========================================================
Maybe a reboot would help?

Vukasin Toroman<vtoroman@astaro.com>
Product Development|Astaro AG
http://www.astaro.com|+49-721-490069-0 Fax -55
----------------------------------------------------------


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Chuck_McDevitt@a-t-t-b-i.com ("Chuck_McDevitt") wrote in message news:<AtYX9.11097$Ve4.1888@sccrnsc03>...
> If I have some code like this:
>
>   try {
>            somefunction();
>        }
>        catch(...)
>       {
>           //do something here
>       }
>
> What is standard behavior if somefunction() causes a
> system exception like seg fault or divide by zero?

System exceptions relate to what the C++ standard calls "undefined
behavior" - which essentially means that the standard no longer
applies to your program.

Of course, system exceptions are specified by some implementations of
the standard - but discussion on this newsgroup relates to the
standard C++.

> At first viewing, I would think catch(...) would catch any
> kind of exception, but there is an inconsistency, since
> even if somefunction is declared to not throw anything,
> it could still throw a seg fault or other system exception.

Clearly, this is a quality of implementation issue - the standard
provides no guidance, but it is desirable that an implementation does
something useful to the developer.

Opinions do differ, but I want an implementation that makes specific
provision for undefined behavior to do so in a way that is accessible
to the developer (and not to disguise it as some form of defined
behavior).

If, for example, a segmentation fault occurs then I would want to
diagnose the problem and take appropriate action at that point in the
program, not try to decipher the problem following unwinding the call
stack and potentially trying to continue running after "catch (...)".

--
Alan Griffiths
http://www.octopull.demon.co.uk/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

If I have some code like this:

  try {
           somefunction();
       }
       catch(...)
      {
          //do something here
      }

What is standard behavior if somefunction() causes a
system exception like seg fault or divide by zero?

At first viewing, I would think catch(...) would catch any
kind of exception, but there is an inconsistency, since
even if somefunction is declared to not throw anything,
it could still throw a seg fault or other system exception.

Are exceptions other than those caused by "throw" just
not part of the standard at all?

Or can a compiler never optimize away a try catch even if
the only code in the try is declared to never throw?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <AtYX9.11097$Ve4.1888@sccrnsc03>, Chuck_McDevitt
<Chuck_McDevitt@a-t-t-b-i.com> wrote:
> What is standard behavior if somefunction() causes a
> system exception like seg fault or divide by zero?

I believe system exceptions are not processed by the standard C++
throw/try/catch mechanism.  On most systems, a platform-specific way of
registering an object or function for exception callback is available.
If my memory serves, POSIX offers sigaction(), Carbon offers
InstallExceptionHandler(), and Win32 offers a __try/__except syntax
that processes the exceptions in a way somewhat more like C++.

 -- A Cappella Guy

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Chuck_McDevitt"" <Chuck_McDevitt@a-t-t-b-i.com> wrote in message
news:AtYX9.11097$Ve4.1888@sccrnsc03...
> If I have some code like this:
>
>   try {
>            somefunction();
>        }
>        catch(...)
>       {
>           //do something here
>       }
>
> What is standard behavior if somefunction() causes a
> system exception like seg fault or divide by zero?
>
> At first viewing, I would think catch(...) would catch any
> kind of exception, but there is an inconsistency, since
> even if somefunction is declared to not throw anything,
> it could still throw a seg fault or other system exception.
>
> Are exceptions other than those caused by "throw" just
> not part of the standard at all?
>
> Or can a compiler never optimize away a try catch even if
> the only code in the try is declared to never throw?
>
>

It will be said that segfault, divide by zero, etc. fall under "undefined
behavior", so anything goes as to whether catch(..) sees it or not, or
anything even remotely sensible happens or not. However, I recommend just
stay (far) away from catch(...) and avoid the whole mess in general. There
are very few truly valid cases for using catch(...). What are you really
trying to catch? If somefunction() is defined to not throw any C++ defined
exceptions, why put any try/catch block around it at all?

hys
--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]