Can C++ programs use C libraries?

Quote:

---

Stober: Ever hear of divide by zero errors?

---

Divided by zero is a CPU exception. It is NOT a C++ exception. You can not generate a divided by zero C++ exception. We are talking about C++ exception here that you manually generate by "throw".

Quote:

---

What is the square root of negative five?

What is log(-1)?

What is tan(90 degrees)?

... were you joking?

---

Mathematically, all these calculation will give you a valid result.

Computerwise, None of these functions throws a C++ exception. Even if they want to throw a C++ exception they don't know how, since they are C functions. So they are irrelevant to our discussion about C++ exceptions.

BTW, these functions do return something that indicates invalid result. Check it out.

I like to thank everyone who replied. You have provided really valuable information and insights with regard to the topic on exception handling.

I didn't mean to start an argument here. Never expect this thread to explode into such a furious debate as well. If anyone is seriously upset about the whole discussion, I'm truly apologetic.

Thanks, once again.

Quote:

---

If you are to do a statistics of what percentage of code would try to catch an exception right where it occurs, instead of let it propagate several levels up, you would find that the ratio is far below 15%.

---

I repeat again, and again, and you always ignore me (not that i'm surprised), stop making stuff up and posting it as fact.

I refuse to argue anything else, because, frankly, you're likely to lie again and again. Which makes meaningful discourse with you an impossibility.

Regards,
Bassman

Folks, Mai doesn't even believe in technical support.

Here is the thread:

http://www.codeguru.com/forum/showth...g&pagenumber=2

According to Mai, technical support is not needed(!!), and he gives the extremes of 2 failures out of a million, and 1 out of 10 failures (as if a large software product written for today's environments falls on either end of this scale).

Note the same thinking from his last message:

Quote:

---

And, are you trying to tell me that you are treating your end users as your QA testers without pay?

---

This is an absolute inanity. Large software products are QA tested very thouroughly, and can still fail, but at a very small rate. Not one in 1 million, but the rate is much smaller than the fictitious "1 out of 10" strawman you brought up. For those rare failures, exception handling is well worth it, instead of giving no technical support, no error logging, and just shrug your shoulders, claiming that it is a "user error" because you write "correct code.

And are you stating that all of those C++ math libraries are done by inferior programmers who don't see the great and wise ways of returning error codes? Why do all of the authors of the libraries listed use exceptions? Is this another "Stroustrup and all of the ANSI committee is wrong" moment from you? You really do like tilting at windmills...

Regards,

Paul McKenzie

Quote:

---

You are wrong. It is exactly the opposite. If the function I call throws an exception and I did not catch it, you can't blame me.

---

Of course you'll be blamed(!) because the very first function that you call will have an "exception specification" (remember those) explicitly telling you that it may throw something. It matters not where the exception comes from (20 functions deep or wherever). That's no different than the first function stating that it may return an error code which you'll be blamed for if ignored according to your own diatribes (even though the error code originated from 20 functions deep). Honestly!

Quote:

---

It's one of the problem with C++ exceptions: The standard leaves it OPTIONAL for any of the upper level code to either catch it or let it propagate further up. So who carries the responsibility of handling the error becomes unclear.

---

Read up on EXCEPTION SPECIFICATIONS!!!. A return code is actually more optional than an exception is (and potentially more dangerous if ignored since an ignored exception will terminate by default).

First I would like to clarify a previous post of mine:

Quote:

---

A nice side effect was that it provided a convient way to inject errors for the QA department...

---

Taken in context, I was NOT in any way suggesting that our customers are the "unpayed QA department". Rather having the system calls inside in-line wrappers (which rarely produce ANY performance impact over checking the result code) provides a method for our well-paid (at least that is the opinion of management) in house QA despartment to inject errors.

It can be very difficult to truely inject all of the possible failures that can result from a system call. Even inducing the more common ones is difficult.

By having the code inside a class wrapper, the QA department is able to replace our system calls with their own wrapper class that induces fixed or quasi-random errors. Typical uses of this are sporatic memory allocation failures, socket communication failures, and thread/process deadlocking failures.

Again this was a side effect of wrapping the system calls that has allowed us to simulate problems that could occur in the real world where truely inducing these faults withing the OS code would be difficult or impossible to do (especially on a repatable basis).

1) There are many classes available that will convert an SEH into a C++ exception. This allows items such as math overflows to be converted into C++ exceptions and processed accordingly. Nearly every well written program that uses exceptions installs one of these handlers.


2) Using exceptions does guarentee that the user will process the exception or the execution will leave that users code and return to the next level. This is the entire point. Consider the following code fragment.

Code:

---

int f(CmyClass *&ptr)
{
  if (everythingOK)
    {
    ptr = m_PTR;
    return 0;  // success
    }
  else
    {
      return 123; // some error code
      }
}


// now the user code.

CmyClass *p = &someValidObject;
int rc = f(p)
p->SomeMethod()

---

In this scenario (i.e. not checking the return value of f()) it is impossible to determine if the original object (someValidObject) or the (m_PTR) object is being invoked.

On the other hand, if f() had thrown an exception (instead or returning 123), it would be certain that the function had succeeded.

If the user whated processing to continue regardless of the functioning of f(), then explicit operations (a catch block) would have been required.

Exceptions are much more deterministic than return codes. With execptions it is the same as in the military, if you dont handle it, I will tak it to your commanding officer, and up the chain of command until the president (operating system) if necessary.

Maybe it is just not a good example, but I'd much rather do as follows than use an exception:

Code:

---

// now the user code.

CmyClass *p = &someValidObject;
int rc = f(p)
if(rc == 0)
    p->SomeMethod()

---

Granter the sample code is (overly??) simple. The point is that as the author of f() I can not guarantee that you are going to check the return value. By throwing an exception I can be 100% certain that you are going to be explicitly aware of it (although I can not be sure you will deal with it "properly") or you will no longer have a chance to proceed.

The even bigger issue occurs when a routine which can not possibly generate and error today is modified by its author so that it can generate an error (or a routine which could previously only generate error "A" can now also generate error "B").

It is reasonible to expect EVERY client that uses this routine to be modified in a timely manner?

If you have used a routine that returns void (i.e. it can not generate an error condifiton) in a few hundred locations in a few dozen programs, would you be willing to stake any significant wager on you finding every single one of these and not missing a single one?

Quote:

---

Exceptions are much more deterministic than return codes. With execptions it is the same as in the military, if you dont handle it, I will tak it to your commanding officer, and up the chain of command until the president (operating system) if necessary.

---

The military command system is a good analogy. The way exceptions are handled are exactly you said, basically a soldier at the lowest level could potentially go all the way to the president for something trivial. And the president has no idea what's the problem is and what the soldier wants, and can only simply throw the guy out and ask him never to bother him again since the president has a lot of important things to do.

On the contrary, the return code system is much more rational. You only directly report to your direct supervisor. You never gets to the president directly. Once you report it to your direct boss your duty is done, then it is up to your supervisor to decide whether to dismiss it, handle it himself, or report one level up and let the upper level supervisor to handle it. Isn't it a better system?

Quote:

---

The even bigger issue occurs when a routine which can not possibly generate and error today is modified by its author so that it can generate an error (or a routine which could previously only generate error "A" can now also generate error "B").

---

If a function has changed its interface, then yes, it is time to go through the whole code base and exam each and every instance where it is used and make sure it still makes sense. You have to do it. And you are not allowed miss even one single spot.
A it takes to generate a computer bug is one single spot where one function is mis-used. Is that an unreasonable requirement? I don't think so.

Quote:

---

It is reasonible to expect EVERY client that uses this routine to be modified in a timely manner?

---

It definitely is! Every single client needs to use the routine MUST use it CORRECTLY. If you make 100 calls and 99 calls are correct, that is not good enough. One mis-use out of a million and it is a bug nevertheless. If you double checked every thing but still missed the bug, that is one thing. If you do not even bother to go through it even just once and let the bug slip through, that is another.

As for whether you can do it in a timely manner, it's all up to the original decision of benefit and cost of changing the function interface, and whether or not your time and budget allow you to get it done in a time frame acceptable to you.

Quote:

---

If you have used a routine that returns void (i.e. it can not generate an error condifiton) in a few hundred locations in a few dozen programs, would you be willing to stake any significant wager on you finding every single one of these and not missing a single one?

---

Is it really so hard to come up with an exhaust list where the said function is referenced? Are you willing to bet money on it being difficult? I don't think so at all. Do a global search! Better yet, change the function name slightly. So you will NOT miss a single location. If you miss, the compiler WILL remind you with an un-resolved external error. Actually I think it is a good idea to ALWAYS change the function name some what, when the interface changes. This makes sure you will go through every instance where it is referenced and make appropriate changes.

Of course, with proper application design, you build an exception handling pattern that does not need to infiltrate all one's code, is perfectly scalable, and can smoothly recover from errors. It is a normal part of your object design to map exception flow and handle at appropriate junctures. Of course, you can put some form of invalid default parameter check in most places and maybe fix up everything else in some way to deal with incomplete objects, but now you have built your own non standard exception handling method that is much more difficult to maintain or scale.

And it is really difficult to see how one deals with the generic programming problem of returning a generic type by value or reference, as there is no generic default error return (see boost::any or Volker Simonis' chameleon objects). It is possible to structure things so that you do not have a generic return type, but as above you are propagating incomplete types, and you must separate the error indicator from the object.

And, of course, you need to keep track of which objects are invalid somewhere if you wish for cleanup to even be possible (and is this tracking always possible?). Exception does the clean up in a well defined manner.

I once had to work on a library that some of my company's customers required be written in C. Some of the most fundamental, system level calls were buried 6 function calls down from the exposed library interface. PLEASE NOTE: this was a very well written and tested library -- our customers still sing the praises of it years laters! But, being written in C, we could not use exceptions. Also, we needed to pass all error codes back up to the user (via long return values). This is one example of what our code ended up looking like in each of our functions:

Code:

---

/* Can't return the variable directly b/c of error code */
long GetSomeVariable(SomeVariable* someVar)
{
    long result = OK;  /* enumerated in header file */

    /* Some trace and assert statements here */

    if (someVar == NULL)
    {
        result = INVALID_PARAM;  /* enumerated in header file */
    }
    if (result == OK)
    {
        result = MoreFundamentalCall1();
    }
    if (result == OK)
    {
        result = MoreFundamentalCall2();
    }
    if (result == OK)
    {
        int index;
        for (index=0; index<something; ++index)
        {
            result = MoreFundamentalCall3();
            if (result != OK)
            {
                break;
            }
        }
    }
    if (result == OK)
    {
        result = MoreFundamentalCall4();
    }
    /* etc, etc, etc... */

    /* More trace statements here */

    return result;
}

---

In C++, with exceptions, you could just write:

Code:

---

// Can return the variable directly
SomeVariable GetSomeVariable() throw OurLibException
{
    SomeVariable returnValue;

    // Some trace and assert statements here

    try
    {
        int index;

        MoreFundamentalCall1();
        MoreFundamentalCall2();
        for (index=0; index<something; ++index)
        {
            MoreFundamentalCall3();
        }
        result = MoreFundamentalCall4();

        // etc, etc, etc...
    }
    catch (OurLibException& e)
    {
        // Trace statements concerning exception;

        throw e; // re-throw exception
    }

    // More trace statements here

    return returnValue;
}

---

Now this is a short example. I have discovered our C code would be the ~ 1/3 the size if exceptions were used. I have also discovered:
* Code maintenance takes about twice as long b/c of having to having to write all the "if (result == OK)"'s
* Debugging code also takes about three times as long b/c of (a) all the if statements, and (b) b/c C++ exceptions can contain much more information (reason exception happened, file and line where it happened, state information, text message, ...) where a long just can't (granted we could have passed back a large data structure all the way to the top, but that would have made our C code very innefficient!)

As far as technical support goes, when our customers have the information from the C++ exceptions, they can say "hey, here's where, why, and the state of my system when I got this error, what's going on?" as opposed to "hey I got code 0x402 which translates to 'this object could not ...' -- can you please look into this for me?" I can testify here that figuring out if the customer made a mistake or if we have a bug is much, much easier with the extra information provided by the exceptions.

- Kevin

P.S. Global variables in C just did not work for storing the extra information in C b/c our library was a multithreaded library, and we could not afford to possibly lose error information from one thread when an error from another thread would overwrite it.

Galathaea, Kevin. Thanks for good posts.

The point that people such as Anthony keep missing is that when the author of the "function" and the user of said function are different people (possibly at different companies), there is no possible way for the author to verify that the user is going to check the return code.

Even when the person is the same, mistakes can and will happen. Ideas such as doing a search do not really work. Using Kevin's example code consider the following:

Code:

---

/* Can't return the variable directly b/c of error code */
long GetSomeVariable(SomeVariable* someVar)
{
    long result = OK;  /* enumerated in header file */

    /* Some trace and assert statements here */

    if (someVar == NULL)
    {
        result = INVALID_PARAM;  /* enumerated in header file */
    }
    if (result == OK)
    {
        result = MoreFundamentalCall1();
    }
    if (result == OK)
    {
        result = MoreFundamentalCall2();
    }
    if (result == OK)
    {
        int index;
        for (index=0; index<something; ++index)
        {
            result = MoreFundamentalCall3();
            if (result != OK)
            {
                break;
            }
        }
    }

    // BUG INDUCED AT THIS LEVEL!
    //if (result == OK)

    {
        result = MoreFundamentalCall4();
    }
    /* etc, etc, etc... */

    /* More trace statements here */

    return result;
}

---

I would really like to see a concrete example of a search that would detect the fact that an error in MoreFundamentalCall1 would still result in a bad call to #4

Quote:

---

And, of course, you need to keep track of which objects are invalid somewhere if you wish for cleanup to even be possible (and is this tracking always possible?). Exception does the clean up in a well defined manner.

---

It's exactly the opposite. It is well know that by using exceptions you may have problem clean up allocated resources. For example if you within a function call, you open up a device, initialize it, use it, then clean it up, close it, release it. If you follow the normal flow of how things happen every thing works fine. But if you throw an exception in the middle which was catched a few layers up, then all the cleanup code have been skipped, causing resource leak. The only way of avoiding such thing is you NEVER acquire/release resources except for when you do it in the constructor/destructor.

So usage of exceptions leaks to the so called RAII concept. And the whole thing eventually leads to such extreme code style that basically every thing is done in constructors and destructors, and
the only functions exist are void functions, and the only way a function reports an error is through exceptions. The rational is you never ever need to check for error return code and all errors are handled by exception. So there is no need for any function that returns an error code. But to avoid resource leak, virtually every thing must be done in constructors and destructors.

I have seem such code. It's terrible. It's completely unreadable.

Just out of curiosity here.... What type of companies do you guys work for? What type of projects do you guys work on? Do you write complete solutions for your company/customers or do you write libraries for others to use? I think this will enlighten me (somewhat anyway) as to why people have the opinions they do.

I'm particularly interested in what Galathaea, Anthony Mai, Paul McKenzie, and Sef do. (Of coarse I'd be interested in what the rest of you do too...)

For me, I work in a company that does embeded robitic controls and along with our hardware, we have to supply software libraries. It's pretty exciting getting to interact all the time with the "real world" and dealing with multiple processors, multiple threads, the occasional RTOS, and situations like: "Someone just ran over the control wiring with a forklift, now bring whatever you can to a controlled stop, save important information, and report a meaningful error back to the master computer."

- Kevin