[Kde-pim] MessageQueueJob sends email but returns error

[David Jarvie]

On Sun, March 11, 2012 9:42 pm, Shaheed Haque wrote:
> That's a good question, made tricky by the lack of any ability
> subclass enums. How about something like this:
>
> 1. Have the Job base class define an ErrorCodes enum, with a last
> extension value set to something like 1000.
>
> typedef enum
> {
>     OK = 0,
>     ...
>     EXTENDED_ERROR_START = 1000
> } ErrorCodes;
>
> 2. Each subclass can define its own enum, starting from
> EXTENDED_ERROR_START.
>
> 3. The base class defines a pure "virtual int errorCode();". In other
> words, we use the equivalence of int and enums to smooth over the gap.

There is already an error() method (inherited from KJob). All that is
needed is for error codes to be defined and setError() called.

Cheers,
David.

> 2012/3/11 Kevin Krammer <krammer at kde.org>:
>> On Saturday, 2012-03-10, David Jarvie wrote:
>>
>>> 2) A more general problem is that Akonadi jobs don't return useful
>>> error
>>> codes, only error strings, so it isn't possible for applications to
>>> test
>>> whether they care about the errors. In this particular case, using
>>> sendmail, the fact that an Item hasn't been created in outbox doesn't
>>> really matter, but because KAlarm doesn't know which error has
>>> occurred,
>>> it has to inform the user who will then think that the mail hasn't been
>>> sent, when it actually has been. If Akonadi jobs could return unique
>>> error
>>> codes for each possible error, this would be really useful.
>>
>> Maybe could accumulate a list of errors somewhere on the wiki and then
>> create
>> a header with "topic" namespaces containing error enums.
>>
>> Or would anyone prefer having all relevant error codes as enums inside
>> the
>> respective job's class declaration?

At first sight it would be more manageable to define the error codes in
each Job class. The snag with this is that one job class may want to
return an error code returned by another job class (e.g. StoreResultJob
calls ItemFetchJob and if that returns an error, StoreResultJob may want
to return the ItemFetchJob error instead of its own error code). That
would require each job class to use its own range of error codes,
non-overlapping with other job classes.

Having said that, we may want to be able to return combinations of error
codes - e.g. StoreResultJob may want to return its own error code, with
the ItemFetchJob error code as an additional piece of information. This
would correspond with the way that errorString() works, where each time
the error string is set, it adds the new error string to whatever is
already set. This would require more than the simple error() method which
already exists.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/