Not easily. You could override DicomImage::operator new()
inside the declaration for DicomImage class. Then the actual logic that could fail and return NULL, would go into the operator new() body, not the actual constructor. Once you are inside the constructor it's too late to return NULL, at that point the object is already created. The problem is that operator new() doesn't receive constructor parameters so you may not have information needed in order to fail.
Another way would be to have a factory method or a factory class actually create your instance, so your code would look like:
DicomImage* pImage = CreateDicomImage( "stuff" );
However because your question had "exception handling" in it... and to make, at least the answer, a little more suitable of a programmers SE (as opposed to stackoverflow) question, I do want to point out that you could and should take advantage of exception handling in C++.
When you return NULL, you force all the client code to sprinkle error checking logic right after the call to new DicomImage() which takes away from readability since error checking tends ends up intermingled with actual application logic.
Wouldn't it be better to have code that looks like:
std::unique_ptr< DicomImage > pImage( new DicomImage( "stuff" ) );
pImage->DoSomeCommand();
pImage->DoSomeOtherCommand();
... and not have to worry about "what-if" conditions if creation failed. You could achieve this by using C++ exception handling and having the constructor throw exceptions if creation fails. Setup try-catch block around the chunk of code that deals with this stuff and what goes inside that try block is pure application logic. No error checking polluting the code and no crashes if image creation fails.
...and by using the smart pointer, you also guarantee that if anything later on fails, pImage will always get deleted. So you never need to worry about having to call delete prior to exiting the function.