Hi Laurens and Serge, I'm torn on this one. In general I've left it up to client code to catch exceptions and handle them how they want. In the case of plugins catching the exceptions and passing back an OUT_OF_MEMORY error might be cleanest route. It wouldn't make sense to have some plugins use this, and others not though, so if we are to make this change, then it should be done for all plugins. There are 50+ plugins though, so making this change is something that takes several hours of careful and tedious work. We are very close to a stable release so I'd suggest making such extensive changes after 2.6 goes out.
Robert. On Mon, Jul 21, 2008 at 3:28 PM, Serge Lages <[EMAIL PROTECTED]> wrote: > Hi Laurens, > > I am currently using the Tiff plugin (and others) with large files, and I > use the std::exception to catch the allocations problems (it allows me for > some process to know that there is an allocation problem, clear the object > cache, and try to load again for example). For me it's a method which works > with all plugins, but with your change, the tiff plugin will have a > different behavior, and I will not be able to know if the > ERROR_IN_READING_FILE comes from an allocation problem or not. > > So I recommend to stay like now, having bad_allocations exceptions when we > cannot allocate a buffer, or to move all the plugins to check for > allocations problems and return a specific error for that. But having some > plugins returning an error and others throwing an exception can be really > confusing. > > Cheers, > > On Mon, Jul 21, 2008 at 4:10 PM, Laurens Voerman <[EMAIL PROTECTED]> wrote: >> >> Now with attachment I hope... >> >> Laurens Voerman wrote: >>> >>> Hi Robert, >>> I made a few changes in src\osgPlugins\tiff\ReaderWriterTIFF.cpp to avoid >>> an unexpected program termination when using very lage textures. I an not >>> totally sure about the portability of "new(std::nothrow)" , I need it on my >>> WinXP/Visual studio 2008 Express system where the new operator throws an >>> exeption, instead of returning a null pointer. >>> >>> >>> Second change: return ERROR_IN_READING_FILE on failure seems more >>> appropriate to me. >>> >>> Greetings, Laurens. >>> _______________________________________________ >>> osg-submissions mailing list >>> [email protected] >>> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > > > > -- > Serge Lages > http://www.tharsis-software.com > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
