And oh yes, CPUWizard, I have already seen your buisness site.... What is the most interesting project you worked on?
Printable View
And oh yes, CPUWizard, I have already seen your buisness site.... What is the most interesting project you worked on?
In your example, if you a function's return code need to be checked, it is easy to do a global search to find out all 100 instances where the function is called, and quickly glance them one by one to make sure they are all correctly checked. It is easy because the error return check is always next to where the function call is made.Quote:
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
On the contrary, if a function throws an exception, how do you know the exception is caught. And how do you know it is caught at the appropriate level, instead of un-necessarily propagated to the topmost level or even the OS when it could have been handled at a much lower level?
You would have to look at each instance of the function call. Figure out the whole calling stack for each one. And check each level in the call stack, to see if there is a try/catch that wrapes the call, and further, you need to exam the type of exceptions that each catch catches, to see if it is the match type of exception.
To carry out such a task is virtually impossible.
That's why a greater than half of all software bugs in the real world are associated with "unhandled exceptions".
I've been in the field for almost 20 years mostly working in C and C++. I contracted for about a dozen different companies from the late 80s until 2000 and then left to work on my own million dollar idea which I'm still at. Of course none of this has anything to do with exceptions which are a language construct that usually has little to do with the nature of your company (though the type of app you write may influence whether you use them or not).Quote:
Originally posted by KevinHall
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]
<< This posting has been edited by the admin. Negative comments towards others are in violation of this site's usage>>
<<REMOVED>>
If someone writes a top-level function that invokes another function for instance, then the latter function can either report an error using a return code or an exception (as far as this discussion is concerned anyway). In either case however, the caller knows that they have to trap an error. They know that because the documentation for the function tells you that it either returns a failure code or it throws an exception (in the latter case the "exception specification" on the function prototype will tell you that). It matters not that the function you're calling is invoking yet another function where an error can be propagated from 20 functions deep using a return code or an exception. From the caller's perspective they only know that the function can generate an error and must trap it. They have no clue without reading the code that the function invokes many other functions and the error can originate from way down the call stack. They may not even have the code nor should they have to read it if they're just clients of the code. Only usage documentation is required and that documentation shows either a return code or an expection specification (again, the prototype will show either). So why does <<anyone>> persist in arguing that nobody knows who will trap it nor is <<anyone>> to blame if the guy 20 functions deep does throw an exception. He can clearly see that the function he himself is calling may fail because the exception specification says so. It's no different than testing a return code which he would presumably do and would be blamed for if he didn't. He doesn't seem to understand that it works the same way. If all functions down the hierarchy can fail then all will show either a return code in their signature *or* an exception specification. There is no difference between the two methods <<removed>> if the lower level function wants to handle the error itself then it can easily do so but its exception specification will now show "throw()" instead (meaning it doesn't throw any exceptions). That's the same as changing a function based on return codes to "void" meaning no error is returned. The return code on all upper-level functions may then also show "void" as well if necesary or "throw()" when using exceptions. In fact, the original function being called at the top may now show "void" or "throw()". <<Removed>>
Sef. I don't know why you keep saying that. You obviously don't understand! Clearly you are not talking in plain English.Quote:
He continues to argue for instance that nobody knows who will catch an exception in spite of my repeated references to "exception specifications". If someone writes a top-level function that invokes another function for instance, then the latter function can either report an error using a return code or an exception (as far as this discussion is concerned anyway). In either case however, the caller knows that they have to trap an error. They know that because the documentation for the function tells you that it either returns a failure code or it throws an exception (in the latter case the "exception specification" on the function prototype will tell you that).
The exception specification only says that when you declare a function, you may have a "throw" clause. It is optional, though. You may or may not specify a "throw" clause, and it compiles either way. Also even if you specify a "throw" clause, and it is noticed by the caller of the function, you may still get OTHER types of exception that was not listed in the "throw clause", including those thrown from deep in the calling stack.
The "throw" clause of function declaration is just an un-enforceable empty promise made on the volunteer basis. You can't rely on or trust it at all.
Now step back one step, let's assume every programmer would provide a "throw" clause to their function declaration, and you can trust that no exception will be thrown except for those specified in the "throw" clause, does that guarantee that every exception thrown will be caught, at the right place where it should be caught?
NO!
The problem is in the C++ standard, caller of a function is NOT required to catch an exception thrown from a function it calls? Is that not clear? It's OPTIONAL!!! You may catch it. You may catch an exception and re-throw. Or you may just let it go and let the upper level code to catch it! It's all optional!!! When something is optional you can choose either catch it and not catch it.
The natural tendency of human laziness generally leads such a result that low level code programmer would not catch an exception, thought it would be catched by higher level code. And higher level code wouldn't catch it, thought it must have already been caught by the lower level code already. At the end of day, no one catches it.
That's what I have been saying: No body knows who will catch an exception! You can cry out loud "I am throwing an exception, some one had got to catch it." But the caller of the function is NOT required to catch it. And every one thinks some one else will catch that exception. That's the problem.
It is exactly because the caller of a function is NOT required to catch an exception and it can optionally let it propagate to higher level, that some programmer feel exceptions make it easier to handle error conditions. But the same reason is also the reason why people don't catch exceptions because they always thought it is some one else's responsibility to catch the four lettered exception.
That's why exception is evil. It let's you get away with the easy feeling of not having to handle the error yourself. But you can't get away from proper error handling at each and every level of function call. You get away and you pay a price for it.
I work for something that must work efficiently and reliably all the time and that it is completely impossible to treat the customer's machine as your QA test machine.Quote:
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...)
<< DELETED BY THE ADMIN - Brad >>
:mad: Anthony, what you just wrote is flat out disrespectful! :mad: It's one thing to voice your opinion or even argue about programming concepts (even if your views do go against a vast majority of others), but to start jumping to conclusions and making demeaning comments about other people's jobs and character is innappropriate and should be unacceptable!
I have to say you get on people's nerves very easily in these forums, and I am trying to understand where you come from [i.e. if you work in a fast-paced environment, where you have to take ultimate responsibility for safety yourself, despite any mistakes other people might make downline, then I can understand why you wouldn't want to use exceptions (and can understand some of the stances you take on other topics) -- though personally I have to disagree with a lot of them!] But it has become obvious that you lack any semblance of self control and that attempting to discuss anything with you is almost entirely fruitless! I will voice right now what I bet many others are feeling: Please do not post any longer on Code Guru -- a great forum like this does not need to be polluted by characters such as yours!
What a ****nerve you have. Answering for others that you don't know and disparaging what you think they do for a living. If this latest response from you doesn't get you banned from CodeGuru, no response will. The moderator will get a call.Quote:
Originally posted by AnthonyMai
<< REMOVED BY ADMIN>>
You have no idea where I and others work, or what we do. I have worked from the science field in computing, to being a computer science professor, to producing third party image processing libraries, and more things that I have gotten involved with. I'm no salesman and I've been in computing for 23 years.
Also, you have a lot of nerve of assuming what others do here and to disparage others here. You are as unprofessional in your responses related to programming as you are to your fellow programmer. And yes, I have been responsible for hiring programmers -- given your lack of control, you would not have been hired by me, regardless of how much you think you know.
Regards,
Paul McKenzie
The subject differs from the mesage body.
To Clarify:
You have a C++ program, which calls C functions in compiled library.
No problem
you encapsulate
the include file of the library or the prototypes
in
extern "C" {
your includes or protypes
and then
}
If you have compiled C++ library
and a C program which calls functions in the library, then it is a little bit more complicated, but possible.
And with Surgeonde's posting, I'm closing this thread. If the technical topic needs further discussion, a new thread can be created.
Just a reminder to everyone, this site has an acceptable use policy. There is a link at the bottom of every page (AUP). Negative comments towards others (regardless of what they may have said or done) are not acceptable. By using this site, you agree to this. Please keep the public forums focused on the technical topics and issues without attacking or making negative comments towards other posters. If you feel something is questionable, then state it in a private message.
Thanks,
Brad!