::std sometimes needed, sometimes not

Discussion in 'C++' started by Marcin Vorbrodt, Sep 16, 2003.

  1. Hi there. How come when in one file i unclude <cmath> i need to use
    std::tan(...), and in another file i include <cassert> and std::assert fails
    to compile. Nowhere in my code i do using namespace std; Seams like some
    things in my header files are in std namespace and some are not. Is that
    correct, or is my compiler (mingw, 3.2 i think) horribly broken? :eek:)

    Thanx,
    Martin
    Marcin Vorbrodt, Sep 16, 2003
    #1
    1. Advertising

  2. On Mon, 15 Sep 2003 20:41:01 -0400, "Marcin Vorbrodt" <> wrote:

    >Hi there. How come when in one file i unclude <cmath> i need to use
    >std::tan(...), and in another file i include <cassert> and std::assert fails
    >to compile.


    That's because assert is a macro. It doesn't live in a namespace; no
    macro does. That's one problem with macros; the nice thing about them
    is that they can pick up things like line number and so on.


    >Nowhere in my code i do using namespace std; Seams like some
    >things in my header files are in std namespace and some are not. Is that
    >correct


    Yes, but there are only a handful or so of standard macros.


    >or is my compiler (mingw, 3.2 i think) horribly broken? :eek:)


    Wrt. to some other things, yes, but it's still a very good compiler.
    Alf P. Steinbach, Sep 16, 2003
    #2
    1. Advertising

  3. OK, so is there a "C++" way of doing assert? A standard C++ class/template
    or something that does assert? Also, is there a C++ alternative to <cmath>?

    Thanx,
    Martin


    "Alf P. Steinbach" <> wrote in message
    news:...
    > On Mon, 15 Sep 2003 20:41:01 -0400, "Marcin Vorbrodt"

    <> wrote:
    >
    > >Hi there. How come when in one file i unclude <cmath> i need to use
    > >std::tan(...), and in another file i include <cassert> and std::assert

    fails
    > >to compile.

    >
    > That's because assert is a macro. It doesn't live in a namespace; no
    > macro does. That's one problem with macros; the nice thing about them
    > is that they can pick up things like line number and so on.
    >
    >
    > >Nowhere in my code i do using namespace std; Seams like some
    > >things in my header files are in std namespace and some are not. Is that
    > >correct

    >
    > Yes, but there are only a handful or so of standard macros.
    >
    >
    > >or is my compiler (mingw, 3.2 i think) horribly broken? :eek:)

    >
    > Wrt. to some other things, yes, but it's still a very good compiler.
    >
    Marcin Vorbrodt, Sep 16, 2003
    #3
  4. Marcin Vorbrodt wrote:

    > OK, so is there a "C++" way of doing assert? A standard C++ class/template
    > or something that does assert? Also, is there a C++ alternative to <cmath>?
    >


    Please don't top-post here. Read section 5 of the FAQ for posting
    guidelines:

    http://www.parashift.com/c -faq-lite/

    C++ doesn't have anything assert-like built in (other than assert), but
    you could certainly create something, probably using an exception class
    to carry the information about the error. Stroustrup has an example of
    this somewhere, IIRC. Probably in "The C++ Programming Language".

    <cmath> *is* the C++ alternative.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Sep 16, 2003
    #4
  5. Marcin Vorbrodt

    llewelly Guest

    Kevin Goodsell <> writes:

    > Marcin Vorbrodt wrote:
    >
    > > OK, so is there a "C++" way of doing assert? A standard C++ class/template
    > > or something that does assert? Also, is there a C++ alternative to <cmath>?
    > >

    >
    > Please don't top-post here. Read section 5 of the FAQ for posting
    > guidelines:
    >
    > http://www.parashift.com/c -faq-lite/
    >
    > C++ doesn't have anything assert-like built in (other than assert),
    > but you could certainly create something, probably using an exception
    > class to carry the information about the error.


    Before you write code signaling a programmer error with an exception,
    read this thread on assert versus exceptions:

    http://groups.google.com/groups?threadm=
    or:
    http://tinyurl.com/nhp7

    > Stroustrup has an
    > example of this somewhere, IIRC. Probably in "The C++ Programming
    > Language".

    [snip]

    He does. However, other experts have since argued that is generally
    bad advice.
    llewelly, Sep 16, 2003
    #5
  6. llewelly wrote:

    >
    >
    > Before you write code signaling a programmer error with an exception,
    > read this thread on assert versus exceptions:
    >
    > http://groups.google.com/groups?threadm=
    > or:
    > http://tinyurl.com/nhp7


    I don't know if you were talking specifically about the particular
    message that link goes to, but I don't think I could disagree more with
    this point:

    This sounds like someone who doesn't understand exceptions to me.

    >
    >
    >>Stroustrup has an
    >>example of this somewhere, IIRC. Probably in "The C++ Programming
    >>Language".

    >
    > [snip]
    >
    > He does. However, other experts have since argued that is generally
    > bad advice.


    Reference? Without reading the opposing argument, I'm very likely to
    side with Stroustrup over some generic, unnamed "experts".

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Sep 16, 2003
    #6
  7. Kevin Goodsell wrote:
    > llewelly wrote:


    ...

    >
    >
    >
    > This sounds like someone who doesn't understand exceptions to me.
    >


    OK - time for some friendly debate.

    I'll state that I use exceptions very rarely and hardly ever in
    production code.

    I actually agree the the quote 100% because I have done exactly that and
    found that it is a very acceptable paradigm for developing solid and
    easily maintainable code.

    I have found that exceptions leed to sloppy code by less experienced
    programmers and even some more experienced guys as well.

    However, I'm open to suggestions. I'm only 90% conviced they're next to
    useless. OK OK OK. In some rare circumstances I can see that they are
    an acceptable alternative. In a test framework, I designed, throwing an
    exception was a way to indicate a test failure, abort()ing was
    unsatisfactory since it meant that other tests would have not been able
    to run in that particular framework.
    Gianni Mariani, Sep 16, 2003
    #7
  8. >>

    >>
    >> This sounds like someone who doesn't understand exceptions to me.


    >However, I'm open to suggestions. I'm only 90% conviced they're next to
    >useless. OK OK OK. In some rare circumstances I can see that they are
    >an acceptable alternative. In a test framework, I designed, throwing an
    >exception was a way to indicate a test failure, abort()ing was
    >unsatisfactory since it meant that other tests would have not been able
    >to run in that particular framework.


    I use exceptions primarily for signaling constructor failure, since it
    is the only way. Do you have a workaround or you assume your ctors
    always succeed ? :)

    Jonathan
    Jonathan Mcdougall, Sep 16, 2003
    #8
  9. Jonathan Mcdougall wrote:
    >>>
    >>>
    >>>This sounds like someone who doesn't understand exceptions to me.

    >
    >
    >>However, I'm open to suggestions. I'm only 90% conviced they're next to
    >>useless. OK OK OK. In some rare circumstances I can see that they are
    >>an acceptable alternative. In a test framework, I designed, throwing an
    >>exception was a way to indicate a test failure, abort()ing was
    >>unsatisfactory since it meant that other tests would have not been able
    >>to run in that particular framework.

    >
    >
    > I use exceptions primarily for signaling constructor failure, since it
    > is the only way. Do you have a workaround or you assume your ctors
    > always succeed ? :)
    >


    Very few contructors I create fail. bad_alloc is a given but I usually
    have bigger problems than bad_alloc exceptions. (I think I have yet to
    see a bad_alloc exception thrown in a production environment) With most
    systems now allowing you to overcommit on memory, you're more likely to
    get an access violation/segmentation fault when memory is depleted.

    I'll give you that one, but I think it's rare and hence letting it abort
    may be a suitable alternative most of the time.

    Anything else ?
    Gianni Mariani, Sep 16, 2003
    #9
  10. >>>However, I'm open to suggestions. I'm only 90% conviced they're next to
    >>>useless. OK OK OK. In some rare circumstances I can see that they are
    >>>an acceptable alternative. In a test framework, I designed, throwing an
    >>>exception was a way to indicate a test failure, abort()ing was
    >>>unsatisfactory since it meant that other tests would have not been able
    >>>to run in that particular framework.

    >>
    >>
    >> I use exceptions primarily for signaling constructor failure, since it
    >> is the only way. Do you have a workaround or you assume your ctors
    >> always succeed ? :)
    >>

    >
    >Very few contructors I create fail.


    That's what I thought :)

    >bad_alloc is a given but I usually
    >have bigger problems than bad_alloc exceptions.


    And you usually abort on these problems?

    >(I think I have yet to
    >see a bad_alloc exception thrown in a production environment)


    Happens often when you try to run recent software on old machines,
    believe me :)

    >With most
    >systems now allowing you to overcommit on memory, you're more likely to
    >get an access violation/segmentation fault when memory is depleted.


    Mmm.. I didn't know that.

    >I'll give you that one, but I think it's rare and hence letting it abort
    >may be a suitable alternative most of the time.


    I think aborting is never a suitable alternative. Letting a catchable
    exception propagate is imho bad programming. Trying something else
    (or the same thing), warning the user, asking to save.. you know..
    user-friendly programming. Nothing frustrates me more than a program
    terminating without warning.

    I long believed my programs would never fail as others do, but now I
    try to do "preventive programming".

    I understand there are problems you just cannot foresee or even solve
    during runtime, but I try to do as much as possible to prevent my
    applications from crashing.


    Jonathan
    Jonathan Mcdougall, Sep 16, 2003
    #10
  11. Jonathan Mcdougall wrote:
    ....
    > And you usually abort on these problems?


    Yep.

    >>(I think I have yet to
    >>see a bad_alloc exception thrown in a production environment)

    >
    >
    > Happens often when you try to run recent software on old machines,
    > believe me :)


    Hmm. I have developed software that ran on thousands of machines and
    other problems were reported, but out of memory errors were not among them.


    >
    >
    >>With most
    >>systems now allowing you to overcommit on memory, you're more likely to
    >>get an access violation/segmentation fault when memory is depleted.

    >
    >
    > Mmm.. I didn't know that.


    I may have overstated that a bit, but I have seen this.

    >
    >
    >>I'll give you that one, but I think it's rare and hence letting it abort
    >>may be a suitable alternative most of the time.

    >
    >
    > I think aborting is never a suitable alternative. Letting a catchable
    > exception propagate is imho bad programming.



    On some systems (Unix) you get a nice big fat core file pointing you to
    the code and the reason for the fault. Sounds like a wonderful
    alternative to me !

    .... Trying something else
    > (or the same thing), warning the user, asking to save.. you know..
    > user-friendly programming. Nothing frustrates me more than a program
    > terminating without warning.


    Sometimes there are more important features. If you can solve the
    problem with a memory upgrade, it's often cheaper than complicating your
    code.

    >
    > I long believed my programs would never fail as others do, but now I
    > try to do "preventive programming".
    >
    > I understand there are problems you just cannot foresee or even solve
    > during runtime, but I try to do as much as possible to prevent my
    > applications from crashing.


    Not letting them happen in the first place is the key.

    There are ways to guarentee that you can't get a bad_alloc but it
    requires knowing before-hand what you're going to need - essentially
    pre-allocating the memory.

    Seems like alot of trouble for not alot of gain.

    If I'm not mistaken, it sounds like we may have a different bias but we
    agree on the problem.
    Gianni Mariani, Sep 16, 2003
    #11
  12. Gianni Mariani wrote:
    > Kevin Goodsell wrote:
    >>
    >>
    >>
    >> This sounds like someone who doesn't understand exceptions to me.
    >>

    >
    > OK - time for some friendly debate.
    >
    > I'll state that I use exceptions very rarely and hardly ever in
    > production code.
    >
    > I actually agree the the quote 100% because I have done exactly that and
    > found that it is a very acceptable paradigm for developing solid and
    > easily maintainable code.


    I don't think that library code should ever unilaterally abort the
    program. Besides that, doing so causes objects to go undestructed,
    leading to resource leaks (sure, most modern desktop systems clean up
    when the process terminates, but you can't count on that in portable code).

    I don't understand why you would prefer aborting to throwing an
    exception anyway. What's the worst case for throwing an exception? It's
    not caught, and the program aborts. So by aborting instead of throwing,
    you're ensuring that you always get the worst case.

    >
    > I have found that exceptions leed to sloppy code by less experienced
    > programmers and even some more experienced guys as well.
    >
    > However, I'm open to suggestions. I'm only 90% conviced they're next to
    > useless. OK OK OK. In some rare circumstances I can see that they are
    > an acceptable alternative. In a test framework, I designed, throwing an
    > exception was a way to indicate a test failure, abort()ing was
    > unsatisfactory since it meant that other tests would have not been able
    > to run in that particular framework.


    Well, I have to admit that I don't have a lot of experience actually
    using exception handling, but I like it a lot. I find that it makes code
    considerably easier to write, and less cluttered. During development of
    a library, I just catch everything in main and print the what() string.
    That way when I run a quick test I get a nice little report of what went
    wrong (if anything). In a program using the library I just catch
    wherever is most appropriate.

    I don't know what else to even say about it. It makes things so simple I
    can't imagine why you wouldn't want to use it. I hate having to
    constantly check return values for errors. Speaking of sloppy
    programming, how often do people forget to check return values? It's a
    bit harder to ignore an exception, and easier to track down the
    resulting problem if you do. Ignore a return value and your program may
    limp along in an undefined state for a while before crashing in some
    other part of the program. With an uncaught exception it's immediate,
    and the debugger can show you where it was thrown from.

    I might have to ask you to explain to me what's so bad about exceptions. :-/

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Sep 16, 2003
    #12
  13. Marcin Vorbrodt

    Jerry Coffin Guest

    In article <jrv9b.4832$>,
    says...

    [ commenting on a quote from James Kanze ... ]

    > This sounds like someone who doesn't understand exceptions to me.


    Others would disagree. Just for example, Herb Sutter (author of
    Exceptional C++, More Exceptional C++ and an upcoming and TTBOMK, as yet
    unnamed book on exceptions) lists James Kanze as "guru" here:

    http://www.gotw.ca/gotw/056.htm

    [ ... ]

    > Reference? Without reading the opposing argument, I'm very likely to
    > side with Stroustrup over some generic, unnamed "experts".


    I'm not sure of the arguments in question either, but if James Kanze is
    among those making the argument, I'd guess that at the very least, it's
    worth studying in detail. Herb Sutter isn't the only one who names or
    acknowledges him either -- he is, for example, listed in the
    acknowledgements of a number of books I have handy, including (for one
    example) _C++ In a Nutshell_, from O'Reilly and Associates (who
    generally aren't disposed toward publishing really bad books anyway).

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Sep 16, 2003
    #13
  14. Marcin Vorbrodt

    Jerry Coffin Guest

    In article <Cqx9b.4983$>,
    says...

    [ ... ]

    > I don't understand why you would prefer aborting to throwing an
    > exception anyway. What's the worst case for throwing an exception? It's
    > not caught, and the program aborts. So by aborting instead of throwing,
    > you're ensuring that you always get the worst case.


    A contrast violation means there is something wrong with the code (i.e.
    a bug) that has been found and noted, and needs to be fixed.

    In this case, aborting is a LONG ways from being the worst case. Quite
    the contrary: the worst case is that the problem is allowed to continue
    unnoticed for some arbitrary period of time -- almost inevitably, the
    longer a bug persists, the more difficult and expensive it is to fix.
    Therefore, when you DO find what you're sure is a bug in some code, the
    best case is to ensure that it fails as quickly, dependably and
    spectacularly as possible, so it will be fixed as soon as possible
    instead of being allowed to persist.

    The problem with throwing an exception in a case like this is that it's
    all too easy (and common) for somebody to do something like this:

    int main(int argc, char **argv) {
    do {
    try {
    return real_main(argc, char **argv);
    }
    catch(...) {
    std::cerr<<"Some problem -- retrying\n";
    }
    } while(1);
    return 0; // never really executes
    }

    In fact, almost any instance of "catch(...)" can cover up an almost
    arbitrary collection of problems that the library designer is TRYING to
    make sure get noticed.

    One way to avoid that is to abort instead of throwing an exception -- as
    long as you're sure that what you've got is a bug in the code, and not
    something from which recovery is reasonable, abort() is a better option
    precisely because it prevents any other part of the code from covering
    up the problem.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Sep 16, 2003
    #14
  15. Marcin Vorbrodt

    Attila Feher Guest

    Jerry Coffin wrote:
    > In article <jrv9b.4832$>,
    > says...
    >
    > [ commenting on a quote from James Kanze ... ]
    >
    >> This sounds like someone who doesn't understand exceptions to me.

    >
    > Others would disagree. Just for example, Herb Sutter (author of
    > Exceptional C++, More Exceptional C++ and an upcoming and TTBOMK, as
    > yet unnamed book on exceptions) lists James Kanze as "guru" here:


    James is a guru. A practical one. So some of his advice is not about how
    to do things in a perfect world where all compilers are conforming to the
    standard, but how to do things in the real world. He is a top consultant
    and rather a pragmatic, real-world guy than a language lawyer. It is worth
    to listen to him.

    --
    Attila aka WW
    Attila Feher, Sep 16, 2003
    #15
  16. Jerry Coffin wrote:
    > In article <jrv9b.4832$>,
    > says...
    >
    > [ commenting on a quote from James Kanze ... ]
    >
    >
    >>This sounds like someone who doesn't understand exceptions to me.

    >
    >
    > Others would disagree. Just for example, Herb Sutter (author of
    > Exceptional C++, More Exceptional C++ and an upcoming and TTBOMK, as yet
    > unnamed book on exceptions) lists James Kanze as "guru" here:
    >
    > http://www.gotw.ca/gotw/056.htm
    >
    > [ ... ]
    >
    >
    >>Reference? Without reading the opposing argument, I'm very likely to
    >>side with Stroustrup over some generic, unnamed "experts".

    >
    >
    > I'm not sure of the arguments in question either, but if James Kanze is
    > among those making the argument, I'd guess that at the very least, it's
    > worth studying in detail. Herb Sutter isn't the only one who names or
    > acknowledges him either -- he is, for example, listed in the
    > acknowledgements of a number of books I have handy, including (for one
    > example) _C++ In a Nutshell_, from O'Reilly and Associates (who
    > generally aren't disposed toward publishing really bad books anyway).
    >


    Heh heh. So am I, but I hope no one thinks I'm an expert.
    Regards,
    Buster.
    Buster Copley, Sep 16, 2003
    #16
  17. Jerry Coffin wrote:

    >
    > A contrast violation means there is something wrong with the code (i.e.
    > a bug) that has been found and noted, and needs to be fixed.


    For the record, I wasn't really considering the context of the quoted
    message, just exception handling in general.

    Now, if you were to use exception handling, and base your exceptions off
    the standard exceptions, a contract violation would be considered a
    std::logic_error. There are other types of exceptions that you might use
    that would not be the result of a contract violation.

    But looking at just the contract violation case, obviously it's a bug
    that should be fixed. But at least some bugs always make it into the
    final product. Terminating the program when a problem is found is not a
    very useful behavior from the perspective of the user of the
    application. In fact, I don't think most users would be very happy with
    that.

    >
    > In this case, aborting is a LONG ways from being the worst case. Quite
    > the contrary: the worst case is that the problem is allowed to continue
    > unnoticed for some arbitrary period of time


    Yes, I agree that this is bad. But it only happens if you explicitly
    ignore the exception.

    > -- almost inevitably, the
    > longer a bug persists, the more difficult and expensive it is to fix.
    > Therefore, when you DO find what you're sure is a bug in some code, the
    > best case is to ensure that it fails as quickly, dependably and
    > spectacularly as possible, so it will be fixed as soon as possible
    > instead of being allowed to persist.


    This is not true from the user's perspective, though.

    >
    > The problem with throwing an exception in a case like this is that it's
    > all too easy (and common) for somebody to do something like this:
    >
    > int main(int argc, char **argv) {
    > do {
    > try {
    > return real_main(argc, char **argv);
    > }
    > catch(...) {
    > std::cerr<<"Some problem -- retrying\n";
    > }
    > } while(1);
    > return 0; // never really executes
    > }
    >
    > In fact, almost any instance of "catch(...)" can cover up an almost
    > arbitrary collection of problems that the library designer is TRYING to
    > make sure get noticed.


    Yes, I definitely agree that this is a problem. But one way to look at
    it is that it's not really *your* problem. If you threw the exception,
    you've done your part. If the caller ignores it, then they screwed up.
    But this doesn't make any difference in many cases. If the program
    breaks for the customer, you'll still be in trouble.

    So I see the point, but I don't think aborting is an ideal solution, in
    particular once the program is in the customer's hands. An exception
    could be an ideal solution, if it's not ignored. As far as I know,
    there's no way to be sure of this.

    A few ideas come to mind, but none is anywhere near perfect. You could
    abort or throw depending on a build setting, for example. But if you
    test with abort and ship with throw then you don't even know if the
    catching code is in place or doing anything sensible. You'd have to test
    with throw, and it could be covered up.

    You could try to make an un-ignorable exception, maybe. Suppose your
    exception object includes a 'handled' flag. On construction, this flag
    is false. The catcher must set it to true. On destruction, if the flag
    does not indicate that the exception was handled, the destructor aborts
    the program. The problem is that it can still be ignored, it just takes
    a little more effort (catch, set the flag, do nothing else).

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Sep 16, 2003
    #17
  18. Marcin Vorbrodt

    Mike Wahler Guest

    Marcin Vorbrodt <> wrote in message
    news:bk5m5s$t1e$...
    > Hi there. How come when in one file i unclude <cmath> i need to use
    > std::tan(...), and in another file i include <cassert> and std::assert

    fails
    > to compile. Nowhere in my code i do using namespace std; Seams like some
    > things in my header files are in std namespace and some are not.


    Exactly. Macros are not ('assert' is a macro) in a namespace.
    They cannot be, since they're merely text substitutions.

    > Is that
    > correct, or is my compiler (mingw, 3.2 i think) horribly broken? :eek:)


    It's fine.

    -MIke
    Mike Wahler, Sep 16, 2003
    #18
  19. Marcin Vorbrodt

    llewelly Guest

    Kevin Goodsell <> writes:

    > llewelly wrote:
    >
    > > Before you write code signaling a programmer error with an
    > > exception,
    > > read this thread on assert versus exceptions:
    > > http://groups.google.com/groups?threadm=
    > > or:
    > > http://tinyurl.com/nhp7

    >
    > I don't know if you were talking specifically about the particular
    > message that link goes to, but I don't think I could disagree more
    > with this point:


    That's exactly the point I was referring to.

    >
    >
    >
    > This sounds like someone who doesn't understand exceptions to me.
    >
    > >
    > >>Stroustrup has an
    > >>example of this somewhere, IIRC. Probably in "The C++ Programming
    > >>Language".

    > > [snip]
    > > He does. However, other experts have since argued that is generally
    > > bad advice.

    >
    > Reference? Without reading the opposing argument, I'm very likely to
    > side with Stroustrup over some generic, unnamed "experts".


    Here's David Abrahams, with a similar opinion:
    http://www.boost.org/more/error_handling.html

    As for 'unnamed experts', I felt it was obvious that the name of the
    expert I was referring to was James Kanze. I won't claim his
    opinions should always take precedence over Stroustrup's, but
    IMO, James's posts show plenty of wisdom, experience, and
    insight. (With some errors here and there. :) You should google
    for his posts, and read a few to form your own opinion.

    Finally, you could email Stroustrup for his current opinion on
    whether exceptions should be used to signal programmer
    errors. Maybe it has changed.
    llewelly, Sep 17, 2003
    #19
  20. Marcin Vorbrodt

    llewelly Guest

    Gianni Mariani <> writes:

    > Kevin Goodsell wrote:
    > > llewelly wrote:

    >
    > ..
    >
    > >
    > > This sounds like someone who doesn't understand exceptions to me.
    > >

    >
    > OK - time for some friendly debate.
    >
    > I'll state that I use exceptions very rarely and hardly ever in
    > production code.
    >
    > I actually agree the the quote 100% because I have done exactly that
    > and found that it is a very acceptable paradigm for developing solid
    > and easily maintainable code.
    >
    > I have found that exceptions leed to sloppy code by less experienced
    > programmers and even some more experienced guys as well.


    >
    > However, I'm open to suggestions. I'm only 90% conviced they're next
    > to useless.

    [snip]

    Hm. Maybe it isn't clear from this snippet, but from what I know,
    James isn't conviced exceptions are useless. He just thinks they
    should be used for conditions one plans on responding to, and
    *not* for programmer errors. If you read further into the
    referenced thread, you'll see more.
    llewelly, Sep 17, 2003
    #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. John Saunders
    Replies:
    0
    Views:
    444
    John Saunders
    Aug 28, 2003
  2. Nehmo Sergheyev
    Replies:
    1
    Views:
    489
    Andrew Urquhart
    May 9, 2004
  3. Replies:
    1
    Views:
    487
    gkelly
    Nov 29, 2006
  4. Randy Smith
    Replies:
    2
    Views:
    430
    Randy Smith
    Apr 24, 2007
  5. Kamyk
    Replies:
    2
    Views:
    162
    Thomas 'PointedEars' Lahn
    May 8, 2005
Loading...

Share This Page