Hi Mathias, > IMHO we should restrict the use of exceptions to error handling.
( I'd see it the same way. If there weren't those 117 (!!) exceptions in the debugger console just when *starting* an OOo with an empty text document. This includes 4 RuntimeExceptions, which I'd normally consider a reason for program abort. Obviously, the attitude "exceptions are for errors" isn't very wide-spread. Yes, this is *no* argument when designing a new API. But I couldn't resist. ) > In > every case where you throw an exception you should be OK with preventing > futher execution of the code of the caller. In this case, we're talking about insertion into a container, which already (potentially) throws exceptions. So the caller needs to already handle those. More precise, with the existing container interface, which upon insertion only allow to throw IllegalArgument and WrappedTarget (plus ElementExists and so) to indicate failure, it would in any case be up to the container interface to catch, and wrap, the listener exception. Which might in fact be an argument for only allowing the WrappedTargetException at the approval call ... even if this somehow contradicts the semantics of WrappedTargetException, doesn't it? > Wether this is true in your special case is something I can't judge, but > at least I consider it to be the wrong approach for a *generic* API > where each and every failed insert approach will throw an exception, > leaving no way for a basic script to ignore this silently or handle it > without a user interaction even if it would be fine to do so. See above. The container needs to handle and wrap it, and the wrapped exception needs to be handled by the Basic script even today. > We did this mistake in our css.util.XCloseable interface and now we had > to add a locking service that just removes the complexity of the > exception process for those who don't want to or can't deal with it. Can you elaborate on this, for me to better understand the problems of this approach? Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
