WrappedTargetExceptions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

WrappedTargetExceptions

Michael Stahl-3

hi,

i've got an interface to load an arbitrary number of files, where each
load operation may fail independently, but any failure should not abort
the whole operation. so i'd like to throw some kind of compound exception
at the end if at least 1 error occurred.

sb already objected to me abusing WrappedTargetException for this purpose.
any objections to adding this to udkapi:


module com {  module sun {  module star {  module lang {

//=============================================================================

/** This is a checked exception that wraps several exceptions thrown
        by original target(s).
  */
published exception WrappedTargetExceptions : com::sun::star::uno::Exception
{
        //-------------------------------------------------------------------------
        /** The exceptions thrown by target(s).
         */
        sequence<any> TargetExceptions;

};


regards,
michael


--
"C++ is a horrible language. It's made more horrible by the fact that a
  lot of substandard programmers use it, to the point where it's much much
  easier to generate total and utter crap with it. Quite frankly, even if
  the choice of C were to do *nothing* but keep the C++ programmers out,
  that in itself would be a huge reason to use C." -- Linus Torvalds


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: WrappedTargetExceptions

Jörg Barfurth
Michael Stahl schrieb:
>
> hi,
>
> i've got an interface to load an arbitrary number of files, where each
> load operation may fail independently, but any failure should not abort
> the whole operation. so i'd like to throw some kind of compound
> exception at the end if at least 1 error occurred.
>

That seems backwards.

If a single failure means that the entire operation is considered
failed, you should abort with that single exception as soon as the error
occurs. If possible roll back the things you already did first.

If failure of a suboperation is NOT a failure of the entire operation,
then this should be treated as a qualified success. That means it
shouldn't throw, but return, possibly passing out a tally of what worked
and failed. So returning a collection of objects that describes the
status of each suboperation (possibly including the exception object you
caught) would seem to be the more appropriate solution.

- Jörg


--
Joerg Barfurth           phone: +49 40 23646662 / x66662
Software Engineer        mailto:[hidden email]
Desktop Technology       http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: WrappedTargetExceptions

Michael Stahl-3
On 12/12/2008 17:29, Joerg Barfurth wrote:

> Michael Stahl schrieb:
>>
>> hi,
>>
>> i've got an interface to load an arbitrary number of files, where each
>> load operation may fail independently, but any failure should not
>> abort the whole operation. so i'd like to throw some kind of compound
>> exception at the end if at least 1 error occurred.
>>
>
> That seems backwards.
>
> If a single failure means that the entire operation is considered
> failed, you should abort with that single exception as soon as the error
> occurs. If possible roll back the things you already did first.
>
> If failure of a suboperation is NOT a failure of the entire operation,
> then this should be treated as a qualified success. That means it
> shouldn't throw, but return, possibly passing out a tally of what worked
> and failed. So returning a collection of objects that describes the
> status of each suboperation (possibly including the exception object you
> caught) would seem to be the more appropriate solution.

hmm, that is also an idea i had... basically return a sequence<any>,
containing all exceptions that occurred. it seems a bit weird to return
exceptions :)
i'm not sure which variant i prefer.
the problem is that whether a failure is really critical or can be ignored
  cannot really be decided by the component that implements the interface,
but only by the caller.
i guess i could also add a boolean abortOnException parameter... but then
the caller would be forced to think about the issue (can't default
parameters in UNO IDL), which may be unnecessary overhead if he doesn't
care anyway.

michael

--
"Easy reading is damned hard writing." -- Nathaniel Hawthorne


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: WrappedTargetExceptions

frank.schoenheit
Hi Michael,

> i guess i could also add a boolean abortOnException parameter... but then
> the caller would be forced to think about the issue (can't default
> parameters in UNO IDL), which may be unnecessary overhead if he doesn't
> care anyway.

Hmm - callers which don't care about this? They will simply catch and
silence your exception, too, so you will never be able to address this
kind of clients.

In general, I agree to Jörg here - the pattern sounds strange. If you
really cannot decide in your implementation whether or not the occurred
exceptions are errors or not, then a callback might be another option:
Give the method call a XFoo parameter, which is called upon each error,
and can decide how to handle it (bail out, ignore and continue, roll
back everything and return - whatever you need).

Whether or not this is too much overhead compared with your boolean
parameter I do not know, though.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: WrappedTargetExceptions

stephan.bergmann
On 12/14/08 19:52, Frank Schönheit - Sun Microsystems Germany wrote:
> In general, I agree to Jörg here - the pattern sounds strange.

On second thought I too agree with Jörg's evaluation.

> If you really cannot decide in your implementation whether or not the
> occurred exceptions are errors or not, then a callback might be
> another option: Give the method call a XFoo parameter, which is
> called upon each error, and can decide how to handle it (bail out,
> ignore and continue, roll back everything and return - whatever you
> need).

That's the good old com.sun.star.task.XInteractionHandler stuff (where
the idea was borrowed from Common Lisp).

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: WrappedTargetExceptions

frank.schoenheit
Hi Stephan,

> That's the good old com.sun.star.task.XInteractionHandler stuff (where
> the idea was borrowed from Common Lisp).

Yes, XInteractionHandler might match the requirements here. I didn't
dare to mention it, since it's pretty ugly and inconvenient to use.

IMO, we have a tendency to prefer new specialized convenient API over
existing general inconvenient API, which is Good (TM).

Also, I'm not sure that it's really an "interaction" what's needed here.
Depends on the term's definition, I always associated some user input
with this, which might or might not be the case in Michael's scenario.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: WrappedTargetExceptions

stephan.bergmann
On 12/16/08 09:36, Frank Schönheit - Sun Microsystems Germany wrote:
> Yes, XInteractionHandler might match the requirements here. I didn't
> dare to mention it, since it's pretty ugly and inconvenient to use.

Come on.  It's beauty, down to the bone.  ;)

> Also, I'm not sure that it's really an "interaction" what's needed here.
> Depends on the term's definition, I always associated some user input
> with this, which might or might not be the case in Michael's scenario.

Think "interaction" more in the sense that different levels of code
interact two-way (rather than the one-way typical exception mechanism).

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]