Daniel, In general, I agree. I certainly agree that invalid geometry should not cause an exit(), especially from the library. The instances of bu_exit() in the libs was not entirely intentional. They are predominantly the result of refactoring numerous bu_log+exit pairings throughout the code. Another pass through the libraries is still needed to make sure those routines do something better.
The code in question that called bu_exit() should either return an error and/or bu_bomb() instead if it is truly a critical failure. I'll run your test case to see what's going on, but it's probably safe to say that it shouldn't be happening. That said, it's worth mentioning that it is an intentional design philosophy of the core C libraries (libbu, libbn, libwdb, librt) that a few truly exceptional conditions *should* shut down the application. Running out of memory is the prime example. It is intentional that a request for memory should *always* return memory or never return at all so that there is the absolute minimal chance of data corruption. Programs are notoriously horrible at gracefully dealing with out-of-memory situations, and the operating system itself can complicate the matter if memory is full. Even when designed to handle it, the environment ends up being unstable and since the user's data is more important than the application, a shutdown is invoked. Back to the issue at hand, though .. yeah, the libs shouldn't be calling bu_exit(). Those should probably be bu_bomb() calls and/or failure returns depending on the routine. A quick survey indicates there are only a couple dozen instances throughout the libs so it shouldn't be too difficult to clean them up. Cheers! Sean On Tuesday, May 12, 2009, at 04:47AM, "Daniel Roßberg" <[email protected]> wrote: >Attached you can find a BRL-CAD database with a broken cone. I >created intentionally a broken database object to test how BRL-CAD >will handle it. Unfortunately the whole application will be shut down >on the first attempt to ray-trace the cone. There is no chance to >catch this error because exit() is called explicitly. This seems to >be not acceptable to me. > >I would go so far to say that exit() should never be called from the >libraries. Only the overall application can know if exiting is an >appropriate reaction on an error. But then, why is there a bu_exit() >in libbu? > > >Sziasztok, > Daniel > >------------------------------------------------------------------------------ >The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your >production scanning environment may not be a perfect world - but thanks to >Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 >Series Scanner you'll get full speed at 300 dpi even with all image >processing features enabled. http://p.sf.net/sfu/kodak-com >_______________________________________________ >BRL-CAD Developer mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/brlcad-devel > > ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
