C++ exception handling is defective

Discussion in 'C++' started by Zorro, Jan 9, 2007.

  1. Zorro

    Zorro Guest

    Zorro, Jan 9, 2007
    #1
    1. Advertising

  2. Zorro

    Rolf Magnus Guest

    Zorro wrote:

    > The simplicity of stack unraveling of C++ is not without defective
    > consequences. The following article points to C++ examples showing the
    > defects. An engineer aware of defects can avoid hard-to-find bugs.
    >
    >

    http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html

    None of the C++ examples in the PDF linked from there is actually using
    exception handling. They all invoke undefined behavior. They don't show a
    defect in C++'s exception handling, but rather a lack of the author's
    understanding of C++.

    BTW: Those examples are also using the <iostream.h> header that has been
    outdated in C++ for about 10 years now and has actually never even been
    part of the C++ Standard.
     
    Rolf Magnus, Jan 9, 2007
    #2
    1. Advertising

  3. Zorro

    Ian Collins Guest

    Rolf Magnus wrote:
    > Zorro wrote:
    >
    >
    >>The simplicity of stack unraveling of C++ is not without defective
    >>consequences. The following article points to C++ examples showing the
    >>defects. An engineer aware of defects can avoid hard-to-find bugs.
    >>
    >>

    >
    > http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    >
    > None of the C++ examples in the PDF linked from there is actually using
    > exception handling. They all invoke undefined behavior. They don't show a
    > defect in C++'s exception handling, but rather a lack of the author's
    > understanding of C++.
    >

    Agreed, I wonder which compiler and environment produced the results
    claimed.

    > BTW: Those examples are also using the <iostream.h> header that has been
    > outdated in C++ for about 10 years now and has actually never even been
    > part of the C++ Standard.
    >

    Not to mention idiomatic C (void).

    --
    Ian Collins.
     
    Ian Collins, Jan 9, 2007
    #3
  4. Zorro

    David W Guest

    "Zorro" <> wrote in message
    news:...
    > The simplicity of stack unraveling of C++ is not without defective
    > consequences. The following article points to C++ examples showing the
    > defects. An engineer aware of defects can avoid hard-to-find bugs.
    >
    >

    http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defecti
    ve.html

    The fact that the code samples use <iostream.h> and not <iostream> suggests that
    a very old compiler was used to demonstrate the supposed exception bugs. If the
    code is updated for <iostream> and the divisions by zero are replaced by throws
    (/0 causes undefined behaviour) and a more recent compiler is used, I think
    you'll find that the destructor is indeed called when the stack is unwound. It
    looks like a defective compiler rather than a defective language.

    DW
     
    David W, Jan 9, 2007
    #4
  5. David W wrote:

    > The fact that the code samples use <iostream.h> and not <iostream>
    > suggests that a very old compiler was used to demonstrate the supposed
    > exception bugs. If the code is updated for <iostream> and the divisions by
    > zero are replaced by throws (/0 causes undefined behaviour) and a more
    > recent compiler is used, I think you'll find that the destructor is indeed


    Better say a correct compiler. I have seen Borland Kilyx failing to call
    destructors in cases similar to that (but correct). I even asked here if
    the code has some error I failed to see, if I remember well. And Borland
    acknowledged the bug, but failed to provide a solution (at least during the
    time that I have the patience to keep checking).

    --
    Salu2
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jan 10, 2007
    #5
  6. Zorro

    Zorro Guest

    Zorro wrote:
    > The simplicity of stack unraveling of C++ is not without defective
    > consequences. The following article points to C++ examples showing the
    > defects. An engineer aware of defects can avoid hard-to-find bugs.
    >
    > http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    >
    > Regards,
    >
    > http://www.zhmicro.com
    > http://distributed-software.blogspot.com
    > http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en


    This is a common reply to several comments, respectfully.

    1. The use of one or another header file is cosmetic for this example.
    2. When you say a correct compiler will do better, please specify the
    compiler.
    3. Division by 0 happens at system level and is not necessary to turn
    it into a throw.
    4. For this example, the compiler is Microsoft Visual C++ version 6.
    5. The defect is in the technique used. Of course it can be corrected.
    Show me a compiler that has in fact corrected this problem. The point
    is that, it takes a great deal beyond plain stack unraveling to correct
    this problem.
    6. If you are not familiar with the concept, and do not see the real
    issue, avoid revealing it.

    With respect, the best way I could present my response.

    Regards,

    http://www.zhmicro.com
    http://distributed-software.blogspot.com
    http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
     
    Zorro, Jan 10, 2007
    #6
  7. Zorro

    Ian Collins Guest

    Zorro wrote:
    > Zorro wrote:
    >
    >>The simplicity of stack unraveling of C++ is not without defective
    >>consequences. The following article points to C++ examples showing the
    >>defects. An engineer aware of defects can avoid hard-to-find bugs.
    >>
    >>http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    >>
    >>Regards,
    >>
    >>http://www.zhmicro.com
    >>http://distributed-software.blogspot.com
    >>http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en

    >
    >
    > This is a common reply to several comments, respectfully.
    >
    > 1. The use of one or another header file is cosmetic for this example.


    It may or may not be cosmetic, but is asking for flak.

    > 2. When you say a correct compiler will do better, please specify the
    > compiler.


    Changing you example to standard C++:

    #include <iostream>

    struct simple
    {
    int s;
    simple() { s = 5;}
    ~simple(void) {std::cout << "Destructor ..." << std::endl;}
    };

    int main(){
    int i = 1, j = 0;
    try {
    simple spl;
    throw 0;
    }
    catch(...) {
    std::cout << "Caught it" << std::endl;
    }
    std::cout << "Finishing" << std::endl;
    return 0;
    }

    any compiler should give the correct result. If not, it is broken.

    > 3. Division by 0 happens at system level and is not necessary to turn
    > it into a throw.


    Then why use it in your examples?

    > 4. For this example, the compiler is Microsoft Visual C++ version 6.


    Old and not very compliant.

    > 5. The defect is in the technique used. Of course it can be corrected.
    > Show me a compiler that has in fact corrected this problem. The point
    > is that, it takes a great deal beyond plain stack unraveling to correct
    > this problem.


    Show me one that exibits it.

    > 6. If you are not familiar with the concept, and do not see the real
    > issue, avoid revealing it.
    >

    Which concept?

    --
    Ian Collins.
     
    Ian Collins, Jan 10, 2007
    #7
  8. Zorro

    Kai-Uwe Bux Guest

    Zorro wrote:

    >
    > Zorro wrote:
    >> The simplicity of stack unraveling of C++ is not without defective
    >> consequences. The following article points to C++ examples showing the
    >> defects. An engineer aware of defects can avoid hard-to-find bugs.
    >>
    >>

    http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    >>
    >> Regards,
    >>
    >> http://www.zhmicro.com
    >> http://distributed-software.blogspot.com
    >> http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en

    >
    > This is a common reply to several comments, respectfully.
    >
    > 1. The use of one or another header file is cosmetic for this example.
    > 2. When you say a correct compiler will do better, please specify the
    > compiler.


    Your compiler did just fine. The output you present is a perfectly valid
    output for the program.

    > 3. Division by 0 happens at system level and is not necessary to turn
    > it into a throw.


    The problem with the division by 0 is that it simply is undefined behavior
    according to the standard. The language specification places no
    requirements upon the observable behavior of any program that executed a
    division by 0. Therefore, the output you attribute to incorrect handling of
    exceptions is a perfectly valid output for your program (and so would be
    any other).

    What puts your program into an inconsistent state is not some exception but
    the division by 0, which is UB.

    > 4. For this example, the compiler is Microsoft Visual C++ version 6.
    > 5. The defect is in the technique used. Of course it can be corrected.


    The defect lies in the undefined behavior.

    > Show me a compiler that has in fact corrected this problem. The point
    > is that, it takes a great deal beyond plain stack unraveling to correct
    > this problem.


    Your program does not illustrate problem with stack unravelling. It
    illustrates that all bets are off once you have undefined behavior.

    > 6. If you are not familiar with the concept, and do not see the real
    > issue, avoid revealing it.


    Huh?


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Jan 10, 2007
    #8
  9. Zorro

    Zorro Guest

    Kai-Uwe Bux wrote:
    > Zorro wrote:
    >
    > >
    > > Zorro wrote:
    > >> The simplicity of stack unraveling of C++ is not without defective
    > >> consequences. The following article points to C++ examples showing the
    > >> defects. An engineer aware of defects can avoid hard-to-find bugs.
    > >>
    > >>

    > http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    > >>
    > >> Regards,
    > >>
    > >> http://www.zhmicro.com
    > >> http://distributed-software.blogspot.com
    > >> http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en

    > >
    > > This is a common reply to several comments, respectfully.
    > >
    > > 1. The use of one or another header file is cosmetic for this example.
    > > 2. When you say a correct compiler will do better, please specify the
    > > compiler.

    >
    > Your compiler did just fine. The output you present is a perfectly valid
    > output for the program.
    >
    > > 3. Division by 0 happens at system level and is not necessary to turn
    > > it into a throw.

    >
    > The problem with the division by 0 is that it simply is undefined behavior
    > according to the standard. The language specification places no
    > requirements upon the observable behavior of any program that executed a
    > division by 0. Therefore, the output you attribute to incorrect handling of
    > exceptions is a perfectly valid output for your program (and so would be
    > any other).
    >
    > What puts your program into an inconsistent state is not some exception but
    > the division by 0, which is UB.
    >
    > > 4. For this example, the compiler is Microsoft Visual C++ version 6.
    > > 5. The defect is in the technique used. Of course it can be corrected.

    >
    > The defect lies in the undefined behavior.
    >
    > > Show me a compiler that has in fact corrected this problem. The point
    > > is that, it takes a great deal beyond plain stack unraveling to correct
    > > this problem.

    >
    > Your program does not illustrate problem with stack unravelling. It
    > illustrates that all bets are off once you have undefined behavior.
    >
    > > 6. If you are not familiar with the concept, and do not see the real
    > > issue, avoid revealing it.

    >
    > Huh?
    >
    >
    > Best
    >
    > Kai-Uwe Bux


    Kai-Uwe, division by 0 is undefined just as trying to deref a null
    pointer. These are exceptional cases that can happen. Simply calling
    them (undefined behavior) does not help in anyway. Are you saying that,
    if one of these cases, or many similar ones, happens the program should
    necessarily terminate? Then what is the point of having an exception
    mechanism?
    Yes, the output is correct in accordance to C++ standard. But, is it
    acceptable just because that is how it is?

    Thanks for your contribution as it brought one more point to attention.

    Regards,

    http://www.zhmicro.com
    http://distributed-software.blogspot.com
    http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
     
    Zorro, Jan 10, 2007
    #9
  10. Zorro

    Zorro Guest

    Ian Collins wrote:
    > Zorro wrote:
    > > Zorro wrote:
    > >
    > >>The simplicity of stack unraveling of C++ is not without defective
    > >>consequences. The following article points to C++ examples showing the
    > >>defects. An engineer aware of defects can avoid hard-to-find bugs.
    > >>
    > >>http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    > >>
    > >>Regards,
    > >>
    > >>http://www.zhmicro.com
    > >>http://distributed-software.blogspot.com
    > >>http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en

    > >
    > >
    > > This is a common reply to several comments, respectfully.
    > >
    > > 1. The use of one or another header file is cosmetic for this example.

    >
    > It may or may not be cosmetic, but is asking for flak.
    >
    > > 2. When you say a correct compiler will do better, please specify the
    > > compiler.

    >
    > Changing you example to standard C++:
    >
    > #include <iostream>
    >
    > struct simple
    > {
    > int s;
    > simple() { s = 5;}
    > ~simple(void) {std::cout << "Destructor ..." << std::endl;}
    > };
    >
    > int main(){
    > int i = 1, j = 0;
    > try {
    > simple spl;
    > throw 0;
    > }
    > catch(...) {
    > std::cout << "Caught it" << std::endl;
    > }
    > std::cout << "Finishing" << std::endl;
    > return 0;
    > }
    >
    > any compiler should give the correct result. If not, it is broken.
    >
    > > 3. Division by 0 happens at system level and is not necessary to turn
    > > it into a throw.

    >
    > Then why use it in your examples?
    >
    > > 4. For this example, the compiler is Microsoft Visual C++ version 6.

    >
    > Old and not very compliant.
    >
    > > 5. The defect is in the technique used. Of course it can be corrected.
    > > Show me a compiler that has in fact corrected this problem. The point
    > > is that, it takes a great deal beyond plain stack unraveling to correct
    > > this problem.

    >
    > Show me one that exibits it.
    >
    > > 6. If you are not familiar with the concept, and do not see the real
    > > issue, avoid revealing it.
    > >

    > Which concept?
    >
    > --
    > Ian Collins.


    Ian, the stream library for output is not the issue. I only tried to
    write less because that was not the point. However, you are replacing
    division by 0 with a throw. What the example is speaking of is about
    exceptions that can happen without you throwing them. Although I am not
    saying that your version does not fail.

    The concept I am referring to is exceptional events that can happen as
    your program executes. For instance, the operating system does not die
    on a division by 0. It simply aborts your program. Thus, the point is
    that, a C++ compiler's run-time library must sense and report such
    events to your program so you can do something about them. Indeed, in
    this example the compiler does report. The problem is the way the
    run-time library is handling the recovery, known as stack unraveling.
    One needs to do a few more things as housekeeping besides popping the
    stack, and passing the exception to the next call.

    Thanks for your comment.

    Regards,

    http://www.zhmicro.com
    http://distributed-software.blogspot.com
    http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
     
    Zorro, Jan 10, 2007
    #10
  11. Zorro

    Kai-Uwe Bux Guest

    Zorro wrote:

    >
    > Kai-Uwe Bux wrote:
    >> Zorro wrote:
    >>
    >> >
    >> > Zorro wrote:
    >> >> The simplicity of stack unraveling of C++ is not without defective
    >> >> consequences. The following article points to C++ examples showing the
    >> >> defects. An engineer aware of defects can avoid hard-to-find bugs.
    >> >>
    >> >>

    >>

    http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    >> >>
    >> >> Regards,
    >> >>
    >> >> http://www.zhmicro.com
    >> >> http://distributed-software.blogspot.com
    >> >> http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
    >> >

    [snip]
    >> > 2. When you say a correct compiler will do better, please specify the
    >> > compiler.

    >>
    >> Your compiler did just fine. The output you present is a perfectly valid
    >> output for the program.
    >>
    >> > 3. Division by 0 happens at system level and is not necessary to turn
    >> > it into a throw.

    >>
    >> The problem with the division by 0 is that it simply is undefined
    >> behavior according to the standard. The language specification places no
    >> requirements upon the observable behavior of any program that executed a
    >> division by 0. Therefore, the output you attribute to incorrect handling
    >> of exceptions is a perfectly valid output for your program (and so would
    >> be any other).
    >>
    >> What puts your program into an inconsistent state is not some exception
    >> but the division by 0, which is UB.

    [snip]
    >
    > Kai-Uwe, division by 0 is undefined just as trying to deref a null
    > pointer. These are exceptional cases that can happen. Simply calling
    > them (undefined behavior) does not help in anyway. Are you saying that,
    > if one of these cases, or many similar ones, happens the program should
    > necessarily terminate? Then what is the point of having an exception
    > mechanism?


    The try-throw-catch mechanism is not meant to handle those cases. I have
    outlined the benefit of try-throw-catch in the following post:

    http://groups.google.com/group/comp...=Bux exception assert&rnum=1#e308bdf6553abbc6


    > Yes, the output is correct in accordance to C++ standard. But, is it
    > acceptable just because that is how it is?


    To me, the current state of affairs with regard to dereferencing a null
    pointer or dividing by 0 is acceptable. C++ has basic types that make very
    little guarantees. If you want stronger predictability, you should define
    simple wrapper classes that provide the additional guarantees. For
    instance, I never use pointers directly. Instead I have a simple pointer
    wrapper class. It defines operator* so that an assert() is made to catch
    dereferencing 0. I also have a wrapper template for the floating point
    types (it allows me to overload operator== to do sloppy comparison). This
    also catches division by 0.

    Also note that this solution is more flexible: I use assert() to catch those
    instances, since I consider them bugs. Others may feel that division by 0
    is not so much a bug of the program but something due to faulty input. From
    that point of view throwing an exception may be more appropriate. I would
    not want the language specification make that decision for me.


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Jan 10, 2007
    #11
  12. Zorro

    benben Guest

    Zorro wrote:
    > Ian Collins wrote:
    >> Zorro wrote:
    >>> Zorro wrote:
    >>>
    >>>> The simplicity of stack unraveling of C++ is not without defective
    >>>> consequences. The following article points to C++ examples showing the
    >>>> defects. An engineer aware of defects can avoid hard-to-find bugs.
    >>>>
    >>>> http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    >>>>
    >>>> Regards,
    >>>>
    >>>> http://www.zhmicro.com
    >>>> http://distributed-software.blogspot.com
    >>>> http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
    >>>
    >>> This is a common reply to several comments, respectfully.
    >>>
    >>> 1. The use of one or another header file is cosmetic for this example.

    >> It may or may not be cosmetic, but is asking for flak.
    >>
    >>> 2. When you say a correct compiler will do better, please specify the
    >>> compiler.

    >> Changing you example to standard C++:
    >>
    >> #include <iostream>
    >>
    >> struct simple
    >> {
    >> int s;
    >> simple() { s = 5;}
    >> ~simple(void) {std::cout << "Destructor ..." << std::endl;}
    >> };
    >>
    >> int main(){
    >> int i = 1, j = 0;
    >> try {
    >> simple spl;
    >> throw 0;
    >> }
    >> catch(...) {
    >> std::cout << "Caught it" << std::endl;
    >> }
    >> std::cout << "Finishing" << std::endl;
    >> return 0;
    >> }
    >>
    >> any compiler should give the correct result. If not, it is broken.
    >>
    >>> 3. Division by 0 happens at system level and is not necessary to turn
    >>> it into a throw.

    >> Then why use it in your examples?
    >>
    >>> 4. For this example, the compiler is Microsoft Visual C++ version 6.

    >> Old and not very compliant.
    >>
    >>> 5. The defect is in the technique used. Of course it can be corrected.
    >>> Show me a compiler that has in fact corrected this problem. The point
    >>> is that, it takes a great deal beyond plain stack unraveling to correct
    >>> this problem.

    >> Show me one that exibits it.
    >>
    >>> 6. If you are not familiar with the concept, and do not see the real
    >>> issue, avoid revealing it.
    >>>

    >> Which concept?
    >>
    >> --
    >> Ian Collins.

    >
    > Ian, the stream library for output is not the issue. I only tried to
    > write less because that was not the point. However, you are replacing
    > division by 0 with a throw. What the example is speaking of is about
    > exceptions that can happen without you throwing them. Although I am not
    > saying that your version does not fail.
    >
    > The concept I am referring to is exceptional events that can happen as
    > your program executes. For instance, the operating system does not die
    > on a division by 0. It simply aborts your program. Thus, the point is
    > that, a C++ compiler's run-time library must sense and report such
    > events to your program so you can do something about them. Indeed, in
    > this example the compiler does report. The problem is the way the
    > run-time library is handling the recovery, known as stack unraveling.
    > One needs to do a few more things as housekeeping besides popping the
    > stack, and passing the exception to the next call.


    So you are actually talking about two separate issues:

    1) C++ doesn't throw properly upon divide-by-zero
    2) Objects out of scope are not properly destroyed upon divide-by-zero

    C++ exception is meant for reporting exceptional circumstances, but for
    detecting it. So it is your responsibility to detect and throw properly.

    C++ could have properly throw an exception when you try to divide an int
    by zero. However, this will put up a significant performance penalty
    that not everyone is comfortable with. Alternatively, you can simple
    test the divident and throw your own exception:

    if (j == 0)
    throw divide_by_zero();

    i /= j;

    This is easy, and you can always create your own type that acts in every
    way like an int but throws properly when divided by a zero. So you have
    got choices to choose from.

    class safe_int
    {
    int repr;

    // ...
    };

    safe_int operator/=(safe_int lhs, int rhs)
    {
    if (rhs == 0) throw divide_by_zero();
    lhs.repr /= rhs;
    return lhs;
    }


    Once 1) is solved (by using a test or using your own int-like class),
    issue 2) is easy. Since the division is no longer a UB, objects out of
    scope are guaranteed to be destroyed properly.

    Oh btw, please please stop using old compilers!

    Regards,
    Ben

    >
    > Thanks for your comment.
    >
    > Regards,
    >
    > http://www.zhmicro.com
    > http://distributed-software.blogspot.com
    > http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
    >
     
    benben, Jan 10, 2007
    #12
  13. Zorro

    jalina Guest

    Zorro a écrit :

    > Yes, the output is correct in accordance to C++ standard. But, is it
    > acceptable just because that is how it is?
    >


    Well this is how C++ has been defined by "philosophy" (no overhead in
    generated code, i.e. no test when dividing to check for 0 division so no
    exception raised)

    I suggest you to look at the ADA language if you want an exception to be
    raised when dividing by 0 (I mean without having to throw it yourself)
    or when accessing an invalid index in a array or even when there is an
    overflow.

    J.


    > Thanks for your contribution as it brought one more point to attention.
    >
    > Regards,
    >
    > http://www.zhmicro.com
    > http://distributed-software.blogspot.com
    > http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
    >
     
    jalina, Jan 10, 2007
    #13
  14. Zorro

    Ian Collins Guest

    Zorro wrote:
    > Ian Collins wrote:
    >>
    >>Which concept?
    >>

    >

    First, please reply inline and trim signatures.
    >
    > Ian, the stream library for output is not the issue. I only tried to
    > write less because that was not the point. However, you are replacing
    > division by 0 with a throw. What the example is speaking of is about
    > exceptions that can happen without you throwing them. Although I am not
    > saying that your version does not fail.
    >

    Then you aren't talking about exceptions in the C++ sense of the term.
    You are talking about events that are beyond the standard.

    > The concept I am referring to is exceptional events that can happen as
    > your program executes. For instance, the operating system does not die
    > on a division by 0. It simply aborts your program. Thus, the point is
    > that, a C++ compiler's run-time library must sense and report such
    > events to your program so you can do something about them. Indeed, in
    > this example the compiler does report. The problem is the way the
    > run-time library is handling the recovery, known as stack unraveling.
    > One needs to do a few more things as housekeeping besides popping the
    > stack, and passing the exception to the next call.
    >

    It any not be possible for this to happen on many platforms without
    checking each and every memory access or operation, which would be
    intolerable.

    --
    Ian Collins.
     
    Ian Collins, Jan 10, 2007
    #14
  15. Zorro

    Dizzy Guest

    Zorro wrote:

    > Kai-Uwe, division by 0 is undefined just as trying to deref a null
    > pointer. These are exceptional cases that can happen. Simply calling
    > them (undefined behavior) does not help in anyway.


    It helps in some (other than yours) situations. You see, one design goals of
    C++ is to not pay for something you don't use/need. While _you_ would like
    the language to check for division by 0 and throw some exception in that
    case, others (ME for example) would NOT like it as it will make every
    devision in my programs slower for a corner case that I know I never reach.
    Thus infriging on my right to have a faster program and on the principle do
    not pay a price for what you don't need.

    However, at the same time, for people with _your_ needs overloading
    operator/ and company (or other wrapper solution) can be implemented:
    1. easily
    2. it does what you need without making the rest (that don't need it) pay
    for what you need

    So what we have now with the current C++ is a win/win situation. Why fix it
    if it works ?

    > Are you saying that,
    > if one of these cases, or many similar ones, happens the program should
    > necessarily terminate?


    No, UB doesn't mean terminate, it's just undefined what it happens. That is
    you shouldn't do it and if you are unsure (or you KNOW that you might be
    doing it) add checks to avoid it. But for the people (and cases) that are
    100% sure it will never happen there are no checks needed thus we have less
    overhead when we don't need it.

    > Then what is the point of having an exception
    > mechanism?


    To offer syntax and semantics that make it easy to decouple the place of
    error detection with the place of error handling. Also (because it supports
    ordinary types and selects the specific type throwed) to make it flexible
    in reporting information about the error. But certainly I don't think it
    was ment to be used to signal some rare conditions by adding checks where
    not all need them and where they can be added easily by those who need
    them.

    Take another case for example, why doesn't C++ arrays subscript operator
    (which are the C arrays actually) and even the standard library containers
    (such as vector::eek:perator[]) do not check for range and throw something if
    the range is out of bounds ? It is EXACTLY the same reason (however, notice
    that std::vector provides .at() that does check I think so you see, you
    have a choice).

    > Yes, the output is correct in accordance to C++ standard. But, is it
    > acceptable just because that is how it is?


    For the reasons explained above (which apply to dozens other such decisions
    in the C++ standar) YES YES YES! :)

    --
    Dizzy
    http://dizzy.roedu.net
     
    Dizzy, Jan 10, 2007
    #15
  16. Zorro

    Rolf Magnus Guest

    Zorro wrote:

    >
    > Zorro wrote:
    >> The simplicity of stack unraveling of C++ is not without defective
    >> consequences. The following article points to C++ examples showing the
    >> defects. An engineer aware of defects can avoid hard-to-find bugs.
    >>
    >>

    http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    >>
    >> Regards,
    >>
    >> http://www.zhmicro.com
    >> http://distributed-software.blogspot.com
    >> http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en

    >
    > This is a common reply to several comments, respectfully.
    >
    > 1. The use of one or another header file is cosmetic for this example.


    If you are talking about what you consider to be defects in the Standard C++
    language, at least you have to use that. Otherwise, your credibility is
    gone at that point already.

    > 2. When you say a correct compiler will do better, please specify the
    > compiler.


    The compiler's output _is_ correct, just as any other C++ compiler's is.

    > 3. Division by 0 happens at system level and is not necessary to turn
    > it into a throw.


    Exactly. Anything can happen. You just used one specific compiler that
    happens to throw an exception in this case and seems to have a bug. That's
    not a proper basis to conclude that there must be a flaw in C++'s exception
    handling. On my compiler, an exception is never even thrown by that
    program, and C++ doesn't require or even suggest it. So your code basically
    has nothing to do with C++ exceptions. It only has to with the behavior of
    one specific compiler.

    > 4. For this example, the compiler is Microsoft Visual C++ version 6.


    Wow, that's an old one. It's not really known for its standard compliance,
    but who's to blame it? AFAIK, that compiler is even older than the
    standard. It's ancient.

    > 5. The defect is in the technique used. Of course it can be corrected.


    It is in the implementation of the compiler and your assumptions, not in the
    C++ standard.

    > Show me a compiler that has in fact corrected this problem. The point
    > is that, it takes a great deal beyond plain stack unraveling to correct
    > this problem.
    > 6. If you are not familiar with the concept, and do not see the real
    > issue, avoid revealing it.


    Familiar with what concept? You don't seem familiar with the concept of
    undefined behavior.
     
    Rolf Magnus, Jan 10, 2007
    #16
  17. Zorro

    peter koch Guest

    Zorro skrev:
    > The simplicity of stack unraveling of C++ is not without defective
    > consequences. The following article points to C++ examples showing the
    > defects. An engineer aware of defects can avoid hard-to-find bugs.
    >
    > http://distributed-software.blogspot.com/2007/01/c-exception-handling-is-defective.html
    >


    You use a very old (from before the C-standard) C++ compiler, write a
    program that includes non-standard headers and has undefined behavior
    and complain that the output is not what you expected.
    This makes the statement "an engineer aware of defects can avoid
    hard-to-find bugs" funny in a very sad way.
    I hope you can do better than that!

    /Peter
     
    peter koch, Jan 10, 2007
    #17
  18. On 9 Jan 2007 22:31:06 -0800, "Zorro" wrote:
    >division by 0 is undefined just as trying to deref a null
    >pointer. These are exceptional cases that can happen. Simply calling
    >them (undefined behavior) does not help in anyway.


    From K&R B9:
    "The header <signal.h> provides facilities for handling exceptional
    conditions that arise during execution, such as an inerrupt signal
    from an external source or an error in execution.
    ....
    SIGFPE arithmetic error, e.g., zero devide or overflow
    ....
    SIGSEGV illegal storage access, e.g., access outside memory limits"
     
    Roland Pibinger, Jan 10, 2007
    #18
  19. On Jan 10, 6:39 am, "Zorro" <> wrote:
    > This is a common reply to several comments, respectfully.
    >
    > 3. Division by 0 happens at system level and is not necessary to turn
    > it into a throw.


    As others have pointed out, this is not an exception. However that does
    not mean that there does not exist ways to handle it, on a
    POSIX-compatible system you can install a signal-handler for the SIGFPE
    (floating-point exception signal), though you always run the risk of
    getting a signal for some other kind of exception*, though they are not
    that common (they usually terminate the app).

    * When I say exception I don't mean a C++ exception but rather a CPU
    trap exception.

    --
    Erik Wikström
     
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, Jan 10, 2007
    #19
  20. Zorro wrote:

    > 1. The use of one or another header file is cosmetic for this example.


    Is not. In several compilers mixing standard headers and pre-standard ones
    is not supported.

    > 5. The defect is in the technique used. Of course it can be corrected.
    > Show me a compiler that has in fact corrected this problem.


    The problem is in your code, not in the compiler. Dividing by zero you
    invoke undefined behaviour. What your compiler does in that situation, you
    must check what your compiler documentation does, and blame his authors if
    what you see contradicts his documentation. From the standard point of
    view, no matter what it does, is undefined.

    --
    Salu2
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jan 10, 2007
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. DC

    Defective session state?

    DC, Nov 6, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    333
  2. Mark Tarver
    Replies:
    22
    Views:
    1,377
    J Kenneth King
    Apr 26, 2009
  3. Peter
    Replies:
    34
    Views:
    2,018
    James Kanze
    Oct 17, 2009
  4. VSK
    Replies:
    0
    Views:
    268
  5. Iñaki Baz Castillo
    Replies:
    1
    Views:
    218
    Iñaki Baz Castillo
    Apr 15, 2008
Loading...

Share This Page