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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[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: [phone] / x66662
Software Engineer        mailto:joerg.barfurth@...
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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Frank Schoenheit, Sun Microsystems Germany]

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         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Frank Schoenheit, Sun Microsystems Germany]

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         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...