#include <iostream>
#include <string>
using namespace std;
class foo
{
public:
void run() {cout<<"running"<<endl;}
};
foo * thing;
string error;
int main()
{
try
{
thing == NULL;
error = "error";
thing->run();
}
catch(...)
{
cout<<error<<endl;
}
return 0;
}
my program won't crash
Author
I'm trying to write a program that throws an exception, but it doesn't seem to work.
I thought that if I try to access a function in an object that doesn't actually exist (through the pointer, which is NULL), that it would throw an exception; instead, it just runs the function as if the object existed.
This is compiled in ubuntu, using g++ 4.1
below is the output:
HOME$ g++ main.cpp -o test
HOME$ ./test
running
HOME$
Now I'm just confused
First "thing == NULL;" should be "thing = NULL;"
Second: are you sure you haven't called new foo() somewhere?
Second: are you sure you haven't called new foo() somewhere?
Run doesn't use any member variables of foo, so it's not surprising that it works. The this-pointer is never dereferenced, so it doesn't matter what its value is.
If you want it to throw an exception you need to access a member variable in the member function. I haven't tested out this code but it should cause an exception.
Also you need to change
thing == NULL;
to
thing = NULL;
thing == NULL is a comparison not an assignment.
class foo{private: int money;public: void run() {cout<<"running "<<money<<endl;}};Also you need to change
thing == NULL;
to
thing = NULL;
thing == NULL is a comparison not an assignment.
I guess since the "run()" method does not depend on any other part of the foo class, it can be made static...and your compiler must automatically compile that as if it were static. However, the type checker doesn't think its static so "foo->run()" will fail but when you do "foo *thing; thing->run()" this is a runtime check, and here it just runs as a static method. If you change the run method to include some of foo's local data, like printing out a variable, then it will crash.
Author
Thanks everyone, it crashes fine now :)
As for the ==, I feel kind of stupid now.
Now I just have to figure out how to get the exception handling to work...
Segmentation fault (core dumped)
I'm assuming that the try/throw/catch can actually deal with this
As for the ==, I feel kind of stupid now.
Now I just have to figure out how to get the exception handling to work...
Segmentation fault (core dumped)
I'm assuming that the try/throw/catch can actually deal with this
You probably know this already, but memory problems are undefined behavior, not crash - core dump is just most common consequence and the trivial one to report.
So don't count on such tests for validity or catching bad allocations.
So don't count on such tests for validity or catching bad allocations.
Generally, catch(...) {} is bad practice. You should at least catch(const std::exception &) {}, better yet, catch only those exceptions you're actually willing to handle (unless you're implementing the final crash that reports the error to the user in a friendly way).
As far as I know, access violations / segmentation faults are undefined in the C++ standard and there's not guarantee that you can catch those with a catch-all. This is best done by installing a debugger hook on windows machines or using whatever surely exists on linux systems. The code you've shown is not portable (i.e. might only work on MS VC++ but not GCC or vice versa).
-Markus-
As far as I know, access violations / segmentation faults are undefined in the C++ standard and there's not guarantee that you can catch those with a catch-all. This is best done by installing a debugger hook on windows machines or using whatever surely exists on linux systems. The code you've shown is not portable (i.e. might only work on MS VC++ but not GCC or vice versa).
-Markus-
This isn't Java. An access violation or null pointer deferencement doesn't throw a C++ exception..
If you were on Windows 32/64, you would use structured exception handlers (SEH) (__try, __except). If you are on a POSIX (linux) system you would need a signal handler (access violations are OS signals).
If you want to be portable, you could ensure that any place that expects a NULL pointer to be passed, test for each pointer and throw a c++ exception for that NULL pointer before trying to deference it. There would be a slight overhead of doing that for each deferencing though.. (you could also have an OS specific handler)
LeGreg
If you were on Windows 32/64, you would use structured exception handlers (SEH) (__try, __except). If you are on a POSIX (linux) system you would need a signal handler (access violations are OS signals).
If you want to be portable, you could ensure that any place that expects a NULL pointer to be passed, test for each pointer and throw a c++ exception for that NULL pointer before trying to deference it. There would be a slight overhead of doing that for each deferencing though.. (you could also have an OS specific handler)
LeGreg
Quote:Original post by yahastu
I guess since the "run()" method does not depend on any other part of the foo class, it can be made static...and your compiler must automatically compile that as if it were static. However, the type checker doesn't think its static so "foo->run()" will fail but when you do "foo *thing; thing->run()" this is a runtime check, and here it just runs as a static method. If you change the run method to include some of foo's local data, like printing out a variable, then it will crash.
It's not a static method, and it doesn't run as one. The this pointer is still passed into the method, it's just never dereferenced, so it doesn't matter what its value is, as someone mentioned earlier.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
