[Insight-developers] [ITK Community] ObjectFactoryBase throwing uncaught exceptions

[Luis Ibanez]

Scenarios that come to mind are:

1)  Dynamic libraries
2)  Management of plugins
3)  The SpatialObjectReader

In the case of (1), the dynamic factories mechanism of ITK enables
developers to load at run time dynamic libraries that will register
alternative factories for the creation of specific objects. This mechanism
is used in the GPU implementation, for example. In this case the exceptions
are useful to control the cases in which, for some reason (e.g. hardware
differences), the alternative objects couldn't be created.

In the case of (2), (which is a variant of (1)), the exceptions are
addressing
issues in the process of loading dynamic libraries, that are the common
way of implementing plugins.

In the case of (3), the SpatialObject reader instantiates objects via
factories by using names that are read from the input files.


In these cases, it is desirable for application developers to have
the opportunity to catch those exceptions and prevent a crash.



Overall,

The presence of the exception gives the application developer
an opportunity for addressing an issue

Should the application developer chose not to catch an exception,
then an abort would happens anyway. So, it is unclear that there is
any benefit from replacing Exceptions with direct calls to abort(), on
the basis that an application developer may not catch an exception.


Given that ITK is a library, it is undesirable to make direct calls
to abort() or to exit(). The decision to fully quit an application
should be left to the application level.


Calls to abort() exist in the ThirdParty libraries though...
(specially in VNL, HDF5 and GDCM).


Currently, in ITK proper there are only three calls to abort() and they
are all in the itkFloatingPointException.cxx, mostly because the proper
implementation of exception doesn't seem to work correctly in lines 374-377.
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkFloatingPointExceptions.cxx#L374


The Coverity() warnings are real in this case:

       ITK has many uncaught exceptions,... and this is by design.

Those exceptions are signals sent to the application that is using ITK.


It looks like a good case in which we could ignore/silence the Coverity
entries for those cases.



   Luis





On Tue, Jan 14, 2014 at 4:24 PM, Brian Helba <brian.helba at kitware.com>wrote:

> Hello all,
>
> Reviewing some of Coverity's results, I've noticed that there are 283
> "Uncaught exception" defects, all triggered by the same code in
> Modules/Core/Common/src/itkObjectFactoryBase.cxx.
>
> Much of the library and factory loading code in ObjectFactoryBase uses the
> itkGenericExceptionMacro to throw exceptions in cases of unexpected
> conditions or errors. Obviously any user that doesn't enclose their entire
> program in a try block could theoretically have a program crash due to an
> uncaught exception.
>
> The question is: is there a use case where a user would want to catch and
> respond to these sort of library and factory load errors and attempt to
> recover from them? If not, then the exceptions could and perhaps should be
> replaced with a simple abort.
>
> Looking forward to your feedback,
> Brian
>
> --
> Brian Helba
> Medical Imaging
> Kitware, Inc.
>
> _______________________________________________
> 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.php
>
> 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
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/community
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20140114/21ff132a/attachment.html>