The script name and line number are there, just not where you're looking. 

The SDO_PropertyNotFoundException is a subclass of Exception, and as such has properties message, code (currently not used), file, line, and trace. By printing $e->getMessage() you're getting just that, the message property, but if you print the full exception :

print $e->__toString()

or just plain :

print $e

then you get something like: 

exception 'SDO_PropertyNotFoundException' with message 'SDOPropertyNotFoundException
 Filename c:\phpbuild\pecl\sdo\commonj\sdo\typeimpl.cpp
 At line 413 in function "getProperty"
 Message Property not found:bad
' in C:\phpbuild\pecl\sdo\tests\007.php:4
Stack trace:
#0 C:\phpbuild\pecl\sdo\tests\007.php(4): unknown()
#1 {main}

$e->getFile() and $e->getLine() give you these values directly.

At present, the message is coming directly from the SDO for C++ library that we use internally, when we rethrow the C++  SDOPropertyNotFoundException as a PHP SDO_PropertyNotFoundException. Hence the file and line number embedded in that message are those of the original exception, which I agree are totally useless for you, but actually quite useful for us when an error is reported.  

We do intend to overhaul the error handling soon, and will consider at that time hiding the information about the original exception.

How about new switch, --enable-debug for instance, to get these internal exception messages?

PHP programmers have no need to know where, in sdo itself, the exception came from since in 99,9% cases they are the programmers "fault" and we'd need to pin-point where it came from in our scripts. getMessage() seems logical place to get those informations from :)

Thanks,
 Hannes

The message attribute of the exception is intended to be text to describe the error, and does not normally include the file and line, which are available as distinct properties of the exception. For example, if you look at the ReflectionException, another subclass of Exception, 

print $e->getMessage() 

prints just (for example):
Extension blah does not exist

whereas 

print $e

prints (for example):

exception 'ReflectionException' with message 'Extension blah does not exist' in
/path/to/my_script:1
Stack trace:
#0 /path/to/my_script(1): ReflectionExtension->__construct('blah')
#1 {main}

This is the pattern which SDO should follow. So when we come to rework the exception handling, I think we shall make the SDO4CPP exception, if any, available as a separate property of the SDO_Exception. This will remove the confusion from the getMessage() output ... but you'll still need to use either getFile() and getLine(), or print the full exception, if you want to find where the error occurred in the script.

Since the 0.9.0 release, the C++ exception is now a separate property of the SDO_Exception. You'll no longer see it unless you invoke the SDO_Exception::getCause() method.

Ofcourse should I use Exception->getLine()/getFile() to get the details of where the exception got thrown. My fault :)

However, the report was more of a whine to get rid of the c++ messages out of ->getMessage(), which you've fixed.
Thanks :)