Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #12147 > unrolled thread

C++ standard library and exceptions

Back to article view | Back to comp.lang.c++

Contents

  C++ standard library and exceptions ittium <ittium@gmail.com> - 2011-12-08 12:17 +0530
    Re: C++ standard library and exceptions ittium <ittium@gmail.com> - 2011-12-08 12:22 +0530
    Re: C++ standard library and exceptions Goran <goran.pusic@gmail.com> - 2011-12-08 01:02 -0800
      Re: C++ standard library and exceptions ittium <ittium@gmail.com> - 2011-12-08 16:35 +0530
        Re: C++ standard library and exceptions Goran <goran.pusic@gmail.com> - 2011-12-08 05:08 -0800
          Re: C++ standard library and exceptions ittium <ittium@gmail.com> - 2011-12-10 13:46 +0530
            Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-11 05:43 +0100
              Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-12 03:21 +0100
              Re: C++ standard library and exceptions André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-12-12 11:15 +0100
                Re: C++ standard library and exceptions Nobody <nobody@nowhere.com> - 2011-12-12 12:59 +0000
                Re: C++ standard library and exceptions Kaz Kylheku <kaz@kylheku.com> - 2011-12-12 17:28 +0000
                  Re: C++ standard library and exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2011-12-12 12:42 -0600
                    Re: C++ standard library and exceptions Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-12 14:18 -0800
                  Re: C++ standard library and exceptions Sektor van Skijlen <ethouris@gmail.com> - 2011-12-19 02:38 -0800
                    Re: C++ standard library and exceptions 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 03:52 -0800
                Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-13 09:16 +0100
                Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-13 09:17 +0100
                  Re: C++ standard library and exceptions "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> - 2011-12-15 12:14 +0100
                    Re: C++ standard library and exceptions Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-15 15:50 -0800
                      Re: C++ standard library and exceptions hanukas <jukka@liimatta.org> - 2011-12-17 21:57 -0800
                      Re: C++ standard library and exceptions "io_x" <a@b.c.invalid> - 2011-12-19 04:02 +0100
                        Re: C++ standard library and exceptions Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-19 01:32 -0800
                      Re: C++ standard library and exceptions Tobias Müller <troplin@bluewin.ch> - 2011-12-19 07:14 +0000
                        Re: C++ standard library and exceptions Joshua Maurice <joshuamaurice@gmail.com> - 2011-12-19 01:29 -0800

Page 2 of 2 — ← Prev page 1 [2]

#12646

"Joshua Maurice" <joshuamaurice@gmail.com> ha scritto nel messaggio
news:b39eedd8-3f12-470c-9a9c-e3c3ee859c14@l18g2000pro.googlegroups.com...
On Dec 15, 3:14 am, "Wolfgang.Draxinger"
<Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
> On Tue, 13 Dec 2011 09:17:45 +0100
>
> "io_x" <a...@b.c.invalid> wrote:
> > yes but it is better function return error code than seg fault the
> > program e.g
>
> The problem is, that a segfault may corrupt the very error detection
> logic. A segfault in a process means, that there is no way the
> execution of the program can continue without being sure, something
> will break eventually somewhere else.
>
> The only sane reaction to a segfault is a process' equivalent to
> biological apoptosishttp://en.wikipedia.org/wiki/Apoptosis
>
> If you want to gracefully react to a segfault, upon program start fork
> the process and install a handler for the case if it terminates with
> segfault error condition. You could even go as far as attaching to the
> process as debugger and extract the state of the process to give some
> sensible error report.
>
> If you were really crazy -- and I mean in the sense of a lunatic, Joker
> like madness -- you could even try to implement a system the restores
> the process state in the last sane state recorded before commencing the
> action that ultimately led to the segfault (however it's very likely
> the process will segfault again).
>
> A process segfaulting always means, that there is something
> fundamentally broken in the programming itself, which cannot be fixed
> by dealing with a error condition, but only by fixing the errornous
> code itself.

Again, as explained else-thread, several very popular and very
successful programs disagree with you. Examples include Sun's/Oracle's
JVM.

#if these programs do that, without to detect-correct the error in the
#new versions of programs
#they make wrong
#because wrong write in the memory can produce indefinite result...
#
#but i say only it is better some detection first of write in memory
#that can be wrong memory for the program
#so could be no wrong write but there is a detection of the error

[toc] | [prev] | [next] | [standalone]

#12651

On Dec 18, 7:02 pm, "io_x" <a...@b.c.invalid> wrote:
> "Joshua Maurice" <joshuamaur...@gmail.com> ha scritto nel messaggionews:b39eedd8-3f12-470c-9a9c-e3c3ee859c14@l18g2000pro.googlegroups.com...
> On Dec 15, 3:14 am, "Wolfgang.Draxinger"
>
>
>
>
>
>
>
>
>
> <Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
> > On Tue, 13 Dec 2011 09:17:45 +0100
>
> > "io_x" <a...@b.c.invalid> wrote:
> > > yes but it is better function return error code than seg fault the
> > > program e.g
>
> > The problem is, that a segfault may corrupt the very error detection
> > logic. A segfault in a process means, that there is no way the
> > execution of the program can continue without being sure, something
> > will break eventually somewhere else.
>
> > The only sane reaction to a segfault is a process' equivalent to
> > biological apoptosishttp://en.wikipedia.org/wiki/Apoptosis
>
> > If you want to gracefully react to a segfault, upon program start fork
> > the process and install a handler for the case if it terminates with
> > segfault error condition. You could even go as far as attaching to the
> > process as debugger and extract the state of the process to give some
> > sensible error report.
>
> > If you were really crazy -- and I mean in the sense of a lunatic, Joker
> > like madness -- you could even try to implement a system the restores
> > the process state in the last sane state recorded before commencing the
> > action that ultimately led to the segfault (however it's very likely
> > the process will segfault again).
>
> > A process segfaulting always means, that there is something
> > fundamentally broken in the programming itself, which cannot be fixed
> > by dealing with a error condition, but only by fixing the errornous
> > code itself.
>
> Again, as explained else-thread, several very popular and very
> successful programs disagree with you. Examples include Sun's/Oracle's
> JVM.
>
> #if these programs do that, without to detect-correct the error in the
> #new versions of programs
> #they make wrong
> #because wrong write in the memory can produce indefinite result...
> #
> #but i say only it is better some detection first of write in memory
> #that can be wrong memory for the program
> #so could be no wrong write but there is a detection of the error

Null pointer dereferences are undefined behavior by the C++ standard.
Linux, for example, defines the behavior.

Your proposed solution of checking the pointer for null before
accessing carries a cost in the "not thrown" code path - the "test if
0 and branch" instruction(s). The solution that Sun's/Oracle's JVM
uses, that of using segfaults, carries no overhead in the "not thrown"
code path.

[toc] | [prev] | [next] | [standalone]

#12649

Joshua Maurice <joshuamaurice@gmail.com> wrote:
> On Dec 15, 3:14 am, "Wolfgang.Draxinger"
> <Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
>> On Tue, 13 Dec 2011 09:17:45 +0100
>> 
>> "io_x" <a...@b.c.invalid> wrote:
>>> yes but it is better function return error code than seg fault the
>>> program e.g
>> 
>> The problem is, that a segfault may corrupt the very error detection
>> logic. A segfault in a process means, that there is no way the
>> execution of the program can continue without being sure, something
>> will break eventually somewhere else.
>> 
>> The only sane reaction to a segfault is a process' equivalent to
>> biological apoptosishttp://en.wikipedia.org/wiki/Apoptosis
>> 
>> If you want to gracefully react to a segfault, upon program start fork
>> the process and install a handler for the case if it terminates with
>> segfault error condition. You could even go as far as attaching to the
>> process as debugger and extract the state of the process to give some
>> sensible error report.
>> 
>> If you were really crazy -- and I mean in the sense of a lunatic, Joker
>> like madness -- you could even try to implement a system the restores
>> the process state in the last sane state recorded before commencing the
>> action that ultimately led to the segfault (however it's very likely
>> the process will segfault again).
>> 
>> A process segfaulting always means, that there is something
>> fundamentally broken in the programming itself, which cannot be fixed
>> by dealing with a error condition, but only by fixing the errornous
>> code itself.
> 
> Again, as explained else-thread, several very popular and very
> successful programs disagree with you. Examples include Sun's/Oracle's
> JVM.

Such programs are a special case.

1. You can only reliably handle a small subset of segfaults. (Namely NULL
Pointer dereference)

2. Only if you /know/ that no other segfaults can appear.

3. It is probably quite platform specific and therefore not portable.

It is also ok to create a website with many IE specific features if you
/know/ that only IE users will use it but I still wouldn't recommend it.

Tobi

[toc] | [prev] | [next] | [standalone]

#12650

On Dec 18, 11:14 pm, Tobias Müller <trop...@bluewin.ch> wrote:
> Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > On Dec 15, 3:14 am, "Wolfgang.Draxinger"
> >> A process segfaulting always means, that there is something
> >> fundamentally broken in the programming itself, which cannot be fixed
> >> by dealing with a error condition, but only by fixing the errornous
> >> code itself.
>
> > Again, as explained else-thread, several very popular and very
> > successful programs disagree with you. Examples include Sun's/Oracle's
> > JVM.
>
> Such programs are a special case.
>
> 1. You can only reliably handle a small subset of segfaults. (Namely NULL
> Pointer dereference)
>
> 2. Only if you /know/ that no other segfaults can appear.
>
> 3. It is probably quite platform specific and therefore not portable.
>
> It is also ok to create a website with many IE specific features if you
> /know/ that only IE users will use it but I still wouldn't recommend it.

I agree to most of that. I disagree that "not portable" is always
"bad" or "must be avoided". Sometimes non-portable solutions are the
correct solutions, like in the case of the JVM. Thus I corrected the
earlier poster when he posted the following, as he was mistaken.

On Dec 15, 3:14 am, "Wolfgang.Draxinger"
>A process segfaulting always means, that there is something
>fundamentally broken in the programming itself, which cannot be fixed
>by dealing with a error condition, but only by fixing the errornous
>code itself.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web