<div dir="ltr"><div>Scenarios that come to mind are:</div><div><br></div><div>1)  Dynamic libraries<br></div><div><div>2)  Management of plugins</div></div><div>3)  The SpatialObjectReader</div><div><br></div><div>In the case of (1), the dynamic factories mechanism of ITK enables</div>
<div>developers to load at run time dynamic libraries that will register</div><div>alternative factories for the creation of specific objects. This mechanism</div><div>is used in the GPU implementation, for example. In this case the exceptions</div>
<div>are useful to control the cases in which, for some reason (e.g. hardware</div><div>differences), the alternative objects couldn't be created.</div><div><br></div><div>In the case of (2), (which is a variant of (1)), the exceptions are addressing</div>
<div>issues in the process of loading dynamic libraries, that are the common </div><div>way of implementing plugins.</div><div><br></div><div>In the case of (3), the SpatialObject reader instantiates objects via </div><div>
factories by using names that are read from the input files.</div><div><br></div><div><br></div><div>In these cases, it is desirable for application developers to have </div><div>the opportunity to catch those exceptions and prevent a crash.</div>
<div><br></div><div><br></div><div><br></div><div>Overall,</div><div><br></div>The presence of the exception gives the application developer <div>an opportunity for addressing an issue<div><div><br></div><div>Should the application developer chose not to catch an exception, </div>
<div>then an abort would happens anyway. So, it is unclear that there is</div><div>any benefit from replacing Exceptions with direct calls to abort(), on </div><div>the basis that an application developer may not catch an exception.</div>
<div><br></div><div><br></div><div>Given that ITK is a library, it is undesirable to make direct calls </div><div>to abort() or to exit(). The decision to fully quit an application </div><div>should be left to the application level.</div>
<div><br></div><div><br></div><div><div>Calls to abort() exist in the ThirdParty libraries though...</div><div>(specially in VNL, HDF5 and GDCM).</div></div><div><br></div><div><br></div><div>Currently, in ITK proper there are only three calls to abort() and they </div>
<div>are all in the itkFloatingPointException.cxx, mostly because the proper</div><div>implementation of exception doesn't seem to work correctly in lines 374-377.</div><div><a href="https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkFloatingPointExceptions.cxx#L374">https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkFloatingPointExceptions.cxx#L374</a><br>
</div><div><br></div><div><br></div><div>The Coverity() warnings are real in this case:</div><div><br></div><div>       ITK has many uncaught exceptions,... and this is by design. </div><div><br></div><div>Those exceptions are signals sent to the application that is using ITK.</div>
<div><br></div><div><br></div><div>It looks like a good case in which we could ignore/silence the Coverity</div><div>entries for those cases.</div><div><br><br></div><div><br></div><div>   Luis</div><div><br></div><div><br>
</div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 4:24 PM, Brian Helba <span dir="ltr"><<a href="mailto:brian.helba@kitware.com" target="_blank">brian.helba@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello all,<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Looking forward to your feedback,</div><div>Brian</div><span class="HOEnZb"><font color="#888888"><div><div><br></div>-- <br>Brian Helba<br>Medical Imaging<br>Kitware, Inc.<br>
</div></font></span></div>
<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Kitware offers ITK Training Courses, for more information visit:<br>
<a href="http://kitware.com/products/protraining.php" target="_blank">http://kitware.com/products/protraining.php</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at:<br>
<a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-developers" target="_blank">http://www.itk.org/mailman/listinfo/insight-developers</a><br>
<br>_______________________________________________<br>
Community mailing list<br>
<a href="mailto:Community@itk.org">Community@itk.org</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/community" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/community</a><br>
<br></blockquote></div><br></div>