Which exception it is?

[mos]

Hi!
When call a null function pointer will cause a execption, but it can't
be caught as std::exception, then which exception it is?
The following code is a example:

typedef void (*testfunc)(int a);

void test()
{
testfunc func = NULL;
func(10);
iTest* p = NULL;
p->Test(10);
}

int main()
{
try
{
test();
}
catch(std::exception& x)
{
std::cout << "exception: " << x.what() << std::endl;
}
catch(...)
{
std::cout << "unknown" << std::endl;
}
return 0;
}

 

[Gavin Deane]

Hi!
When call a null function pointer will cause a execption,

Says who?

but it can't
be caught as std::exception, then which exception it is?
The following code is a example:

typedef void (*testfunc)(int a);

void test()
{
testfunc func = NULL;
func(10);

Dereferencing a null pointer.

iTest* p = NULL;
p->Test(10);

Dereferencing a null pointer

}

int main()
{
try
{
test();
}
catch(std::exception& x)
{
std::cout << "exception: " << x.what() << std::endl;
}
catch(...)
{
std::cout << "unknown" << std::endl;
}
return 0;
}

Dereferencing a null pointer has undefined behaviour. Anything can
happen. What you implementation does with this code is outside the
scope of the C++ language. There is certainly no reason to expect a C+
+ exception to be thrown. The only thing that will be caught in a
catch block is a C++ exception generated by a throw statement, and
there isn't a throw statement in your code.

Given the right settings, your implementation *may* offer, *as an
extension to the language* (and so, outside the scope of this
newsgroup), predictable behaviour in the event of dereferencing a null
pointer. Your implementation may use the word "exception" to describe
some aspect of that behaviour. However, that is not the same thing as
a C++ exception.

Whether your implementation provides such an extension, how to use it
if it does, and whether it hooks into the C++ try-throw-catch syntax
in some way are all questions that are off-topic in this group. You
need to look in your compiler documentation and ask about it in a
compiler-specific newsgroup. Some suggestions in the FAQ:

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9

Gavin Deane

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Hi!
When call a null function pointer will cause a execption, but it can't
be caught as std::exception, then which exception it is?

No, not an exception, it's an error. I would guess that it will result
in a segfault. What I do know is that it will terminate the application,
you can not recover from this.

 

[Peter]

Hi!
When call a null function pointer will cause a execption, but it can't
be caught as std::exception, then which exception it is?
The following code is a example:

typedef void (*testfunc)(int a);

void test()
{
testfunc func = NULL;
func(10);
iTest* p = NULL;
p->Test(10);
}

int main()
{
try
{
test();
}
catch(std::exception& x)
{
std::cout << "exception: " << x.what() << std::endl;
}
catch(...)
{
std::cout << "unknown" << std::endl;
}
return 0;
}

this is a windows-only feature.
I think it is a useful feature and I don't understand why it is not in the
standard.
Some UNIX gurus probably thought that their signal() implementation is the
best what can be achieved.
On Windows a structured exception will be thrown -- assuming you have
structured exceptions enabled in your compiler.
You can overload the type of exception thrown by setting a handler using the
_set_se_translator() function.
In this handler you would have to throw a C++ Exception yourself -- ideally
a different one for every different code.

 

[Gavin Deane]

this is a windows-only feature.
I think it is a useful feature and I don't understand why it is not in the
standard.

Probably because in general, requiring defined behaviour on
dereferencing a null pointer would imply some runtime overhead on
every pointer dereference, which would go against the C++ philosphy of
"you don't pay for what you don't need".

If you want specific behaviour on dereferencing a null pointer, you
can write your own class that wraps a pointer and checks its value on
dereferencing. If an attempt is made to dereference a null pointer,
you can write whatever behaviour you want in your wrapper class (e.g.
throw an exception).

C++ lets you choose between that control, with its associated overhead
every time a wrapped pointer is dereferenced, and undefined behaviour,
which doesn't have the overhead.

Gavin Deane

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Probably because in general, requiring defined behaviour on
dereferencing a null pointer would imply some runtime overhead on
every pointer dereference, which would go against the C++ philosphy of
"you don't pay for what you don't need".

And I'm not sure if it's even possible to implement (without the
wrapper) on all architectures, I think it requires virtual memory (have
not given it much thought tough).

 

[Peter]

Probably because in general, requiring defined behaviour on
dereferencing a null pointer would imply some runtime overhead on
every pointer dereference, which would go against the C++ philosphy of
"you don't pay for what you don't need".

it does not require runtime overhead.
The only thing which is needed is that one can throw from a signal handler.

 

[BobR]

Hi!
When call a null function pointer will cause a execption, but it can't
be caught as std::exception, then which exception it is?
The following code is a example:

// --------------------------------------
#include <stdexcept>
class MyErr : public std::runtime_error { public:
MyErr( std::string const &msg = "") : std::runtime_error(msg){}
};
// --------------------------------------

typedef void (*testfunc)(int a);

void test() throw(MyErr){

testfunc func = NULL;
func(10);
iTest *p = NULL;

if( not p ){
throw MyErr(__FILE__": my message");}
}

p->Test(10);
}

int main(){
try{
test();
}

catch( MyErr const &x){
std::cout<<" caught MyErr: "<< x.what() <<std::endl;
} // catch(MyErr&)

 

[Bo Persson]

Peter wrote:
:: ::::
:::: ::::: Hi!
::::: When call a null function pointer will cause a execption
:::: this is a windows-only feature.
:::: I think it is a useful feature and I don't understand why it is
:::: not in the
:::: standard.
:::
::: Probably because in general, requiring defined behaviour on
::: dereferencing a null pointer would imply some runtime overhead on
::: every pointer dereference, which would go against the C++
::: philosphy of "you don't pay for what you don't need".
::
::
:: it does not require runtime overhead.
:: The only thing which is needed is that one can throw from a signal
:: handler.

And that requires that dereferencing a null pointer invokes a signal
handler. On systems where this doesn't happen, there will be a huge
runtime overhead if they are required to check all pointer references
anyway.


Bo Persson

 

[Jon Harrop]

When call a null function pointer will cause a execption, but it can't
be caught as std::exception, then which exception it is?

C++ doesn't throw null pointer exceptions, you're thinking of a higher-level
language like Java, C# or managed C++.