need help on exception handling

[amit2483]

i have implemented a try...catch block in a C++ program.
the compiler identifies 'try' and 'catch' as keywords but the program shows error on compilation.
here is the source code of the program.

#include<iostream.h>
#include<conio.h>

class working
{
    private:
        int n1,n2,result;
    public:
        void display()
        {
            n1=1;
            n2=0;

            try
            {
                answer=n1/n2;
                if(!(answer>=0))
                    throw 20;
            }
            catch(int errnum)
            {
                cout<<"exception";
                answer=0;
            }
            cout<<answer;
        }
};
void main()
{
    working myobj;
    myobj.display();
}

[ropez]

What do you mean by "the compiler identifies 'try' and 'catch' as keywords"? If you mean that they are shown in a special color on your screen, it has nothing to do with the compiler, but with your editor.

Your code seems to be correct. I may be that you have disabled exceptions in your copiler/project settings. You need to provide more information: Which compiler are you using? What error message did you get?

[ropez]

BTW:

#include<iostream.h>
#include<conio.h> 

this is deprecated MS-DOS code. Use

#include<iostream>
using namespace std;

[DrDogg]

You have a number of problems that will stop this compiling.

1. The variable answer is never declared. I assume you mean result.
2. main never returns void, it always returns int. If your compiler accepts void, it shouldn't.
3. As ropex points out, iostream.h is deprecated (although MS-DOS has nothing to do with it) and you should use his replacement.
4. If you're hoping to detect division by zero using exception handling, it is not supported by the C++ standard. You should use standard conditional logic (i.e. probably an if statement!) to detect the case where the denominator is zero. This is clearer, probably more efficient and most importantly will actually work.

With those fixes your code compiled and ran for me. (Using gcc 4)

Hope that helps.

[ropez]

@MrDogg:
MS-DOS has nothing to do with <iostream.h>, but <conio.h> was an MS-DOS header, according to wikipedia.

[DrDogg]

Ropex: Fair point. Although I note that conio.h, unlike many features oringinating in DOS, has survived the transition of the MS C library to 32 bits and is alive and well in the platform SDK that ships with MSVC++ 7.1.

Not only that, but conio.h seems to be entirely redundant in the code amit2483 supplied.

[ropez]

It's still deprecated! It's not standard, and probably included for backwards compatibility towards code from the MS-DOS era. Most importantly: IIUC, It contans no funcitonality that isn't avaliable in standard header files like <cstdio>, or better <iostream>

[z05DSL3A]

Just in case there is confusion with our other readers:

Deprecation:
In computer software standards and documentation, the term deprecation is applied to software features that are superseded and should be avoided. Although deprecated features remain in the current version, their use may raise warning messages recommending alternate practices, and deprecation may indicate that the feature will be removed in the future. Features are deprecated—rather than being removed—in order to provide backward compatibility and give programmers using the feature time to bring their code into compliance with the new standard.

From Wikipedia

[DrDogg]

Where is the reference that says conio.h has been officially deprecated as a complete header? I can't find any reference for that in MSDN but that may just be because MSDN can be pretty unweildy.

I can find plenty of functions within it that are deprecated but there is usually a non-deprecated version provided.

[z05DSL3A]

Because conio.h is not part of the C standard you will not have ‘official’ reference to it being deprecated. Each compiler manufacturer will make there own mind up as to how they deal with this file.

With MS if you define !__SDTC__ (I think) you will only have deprecated functions on offer, the header also says it is provided for compatibility.

I think that the GNU Compiler Collection (GCC) dose not have the file at all as its aim is for portability and standards compliance.

Anyway, I think it would be far to say that the use of conio.h should be avoided.

[satm2008]

DrDogg:

>> 2. main never returns void, it always returns int. If your compiler accepts void, it shouldn't.
Wrong. Since C++ is the superceded version of C and in C/C++ standards, the main() can be void unless it needs to return an exit code. So the compiler accepts it and it is normal/standard.

Amit2483:

I am little confused that how can you acheive a a negative value (ie, answer or restult) from the given division as a division does never return a negative value. Hence your exception will never be caught.

And conio.h would probably be complained about by your compiler as most C++ compilers do not recognize/find in the library as it has probably been deprecated.

Other than the code descrepancy in using the result and answer variables, the compiler would not return any other errors.

Check it out. Good luck :)

[z05DSL3A]

@satm2008

Section 3.6.1 Main function paragaph 2 of the 2003 C++ standard:

An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main:
int main() { /* ... */ }
and
int main(int argc, char* argv[]) { /* ... */ }
...

[DrDogg]

satm2008:

Returning int from main is not standard in C++. (See standard clause 3.6.1.2) This is one of a number of incompatibilities with standard C. (See "Exceptional C++" by Herb Sutter, pp76 for his thoughts, probably on http://www.gotw.ca/ somewhere too)

Any number of possible main declarations are possible but the standard dictates that they all must return int and that only two are guaranteed to be allowed:

int main() {}
int main(int, char*[]) {}

A caveat to this is that whilst main must return int, an explicit return statement is not required. Clause 3.6.1.5 states that this is equivalent to return 0;

Some confusion is caused because this incompatibility is not mentioned in Annex C or D where the presence of absence of compatibility features is usually noted.