Re: [Openexr-devel] Exceptions in the DLL

[Paul Schneider]

Hi, Paul,

you're right about requiring that the libraries be built with the same 
compiler, options, etc as the calling app.  However, this is a 
requirement of any C++ interface; if you wanted to inherit from OpenEXR 
classes, for example, you'd have the same problem.  If we stopped the 
library from propagating exceptions, you'd still have this problem.  We 
tried to be clear about what compiler, etc is required for working with 
the libraries, but our documentation could probably be better in this 
regard.

I took a quick look at the C interfaces (ImfCRgbaFile.cpp) and it seems 
to catch any exceptions thrown in exported functions, and return error 
codes instead.  ImfOpenInputFile, for example, is surrounded by a 
try/catch block.  Of course, it's only catching std::exceptions, and I 
seem to remember that the Microsoft compiler likes to throw other kinds 
of exceptions (often in violation of the C++ standard), so maybe that's 
the problem.  If you can find a case where the C interfaces are 
propagating exceptions back from the C library, that's definitely a bug 
that should be fixed.

I haven't read the article you describe, but it sounds like he outlines 
the necessary steps for ensuring that a C++ library can be used from 
another C++ library with a completely different runtime environment.  
However, that was never a design goal of OpenEXR, which is part of the 
reason we supplied the source.  I would hope that as compilers converge 
to a common C++ ABI (real soon now), the need for such acrobatics will 
disappear.

Of course, none of this solves your problem.  You're right, we should 
ship our precompiled libraries with documentation describing exactly 
what development system was used to buid them, and a note explaining 
that those who wish to use a different system should recompile the 
libraries.

- Paul



On Nov 21, 2004, at 9:48 AM, Paul Nolan wrote:

> > C++ exceptions are OpenEXR's mechanism for reporting errors.  If 
> > you're
> > using the library inside an application with a different error 
> > handling
> > mechanism, you should put a try/catch around calls you make to the
> > library, and map the exceptions into your own error code/class.  The
> > OpenEXR library should only throw exception classes that inherit from
> > Iex::Exception, which itself inherits from std::exception.
>
> From what I have read you can only do this if you can guarantee that 
> the
> calling program uses the same compiler revision, compile flags, and
> standard library version.  There is an article by Herb Sutter in this
> months CUG (Dec 04) on the subject that  provides guidelines for 
> creating
> C++ DLLs, his suggestions are to put catch(...) all around externally
> accessible functions, and return error codes instead, plus do not allow
> the calling program to free memory allocated in the DLL, and avoid user
> defined types in externally accessible interfaces.  I would recommend
> either doing this, or adding a big WARNING.TXT file to the directory 
> that
> states what it is safe to use it with, or removing the precompiled DLLs
> all together, as someone might try using them on either a newer or 
> older
> compiler, and not immediately notice problems.
>
> > Or, are you talking about the C interfaces?  Those shouldn't be
> > propagating C++ exceptions, obviously.  Let me know if that's the 
> > case.
>
> It looks like it at first glance, ImfOpenInputFile appears to be 
> throwing
> a wobbly when given a non EXR file.  Hard to say for sure with this
> compiler as it doesn't give much info.
>
> Thanks,
>
> Paul Nolan, CEO Idruna Software Inc.
> http://www.idruna.com