[Insight-developers] SimpleITK Exceptions

[Bradley Lowekamp]

Jim,

Thinking about it, ensuring that all SimpleITK methods catches and rethrows ITK exceptions as simpleITK exceptions sounds like a lot of work and would be error prone. Additionally it would be near impossible to test. So, this may not be a realistic option.

There is an alternative. I believe you can catch both ITK and simple ITK exceptions with the following:

try {
	img = sitk.ReadImage( "file.png" );
}
 catch ( std::exception &e )
{
	std::cerr << "exception: " << e.what() << std::endl;	
}

This should be able to be done without the inclusion of the ITK exception headers. So, I currently don't think that wrapping is needed, just using the existing polymorphism.

However, you could still include the ITK header and explicitly catch ITK exceptions. I would classify this under ITK integration, as it would not be needed but does add extra functionality.

After catching ITK exceptions, I usually catch std::exceptions and "..." other exceptions as well at the top level of my programs. As no guarantee can be given as to what kind of exceptions will be thrown, with out exception specifiers.

Brad

On Mar 16, 2011, at 9:42 PM, Jim Miller wrote:

> What doesn't work right now is only catching simpleitk exceptions as standard itk exceptions will not be caught. 
> 
> I guess you need a simpleitk exception type as wrapping may only be being done at the simpleitk level. 
> 
> If we want to avoid exposure to itk proper headers then we probably need to catch all itk exceptions in simpleitk and rethrow them as simpleitk exceptions
> 
> 
> 
> 
> 
> 
> On Mar 14, 2011, at 5:03 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
>> Jim,
>> 
>> Currently, itk::simple::GenericException is derived from itk::ExceptionObject. You can catch which ever types of exception you prefer, both of your suggestions would currently work. This is one of the few places where SimpleITK is depending on ITK in the headers. So that SimpleITK will not need to include ITK headers to become a standalone library, the SimpleITK exception needs to be rewritten to derived directly from an std::exception, and not itk's exception.
>> 
>> After this change, more thought will need to be put into how to deal with ITK exceptions inside SimpleITK. Currently I am thinking that one of the SimpleITK exception types could hold a ITK exception so it could be accessed via a pointer if needed. This would enable the ITK exception to have a forward declaration. Do you have other suggestions for this?
>> 
>> I don't think it is in the plan to add exception specification to the SimpleITK members or functions. So if you must have an application robust to exceptions you will still need to catch(...) to guarantee getting all cases.
>> 
>> Brad
>> 
>> On Mar 14, 2011, at 4:44 PM, Jim Miller wrote:
>> 
>>> It doesn't appear as though SimpleITK catches ITK exceptions (and translate them into SimpleITK exceptions). Is the expectation that users will explicitly catch both itk::simple::GenericException and itk::ExceptionObject? Or perhaps just catch itk::ExceptionObject as it appears as though itk::simple::GenericException derives from itk::ExceptionObject.
>>> 
>>> 
>>> Jim Miller
>>> Senior Scientist
>>> GE Research 
>>> Interventional and Therapy
>>> 
>>> GE imagination at work
>>> 
>>> <smime.p7s><ATT00001..txt>
>> 
>> 
>> 
>> ========================================================
>> Bradley Lowekamp  
>> Lockheed Martin Contractor for
>> Office of High Performance Computing and Communications
>> National Library of Medicine 
>> blowekamp at mail.nih.gov
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>> 
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110316/34823fcd/attachment-0001.htm>