Frank Schönheit - Sun Microsystems Germany wrote: >> Without having the bigger picture how good error handling should look >> like > > while we are at it, and mentioned UNO incompatibility already ... > > I just came across (yet) another issue where a severe error was silenced > instead of propagated to the caller (and thus caused document > corruption), simply because the respective UNO method (XFilter::filter) > was poorly designed, and did not allow to throw any but a RuntimeException. > > However a reasonable error handling would look like, IMO carefully > re-designing UNO to add more exceptions specifications to (a lot of) > methods is a must-have.
+1 Just to play the devil's advocate: without careful considerations that would end in adding "throws css.uno.Exception" to any method, though perhaps it's the right approach for all generic APIs (generic APIs need generic exceptions - don't they?). While this would be an improvement wrt. being able to fix design flaws, I doubt that this is what we want in every case. It just would create a lot of silently caught exceptions. OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a "big bang" release, we will need quite some time to fix that. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
