[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: KIO/KHTML Error Handling Update
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-02-03 8:14:44
[Download RAW message or body]

> After looking at the current defined messages I think we already have too
> much specific error codes that would have been better served with e.g.
>ERR_SLAVE_DEFINED. I don't want remove existing error codes but I don't
> think we should add more error codes unless that kind of error is either
> common for many slaves or it is needed for the automatic handling of such a
> response. (Eg. like the ERR_UNSUPPORTED_ACTION which makes that a job will
> try do what it wants to do in an alternative way)

I agree with this. The only problem is that, at the moment, ERR_SLAVE_DEFINED 
won't fit into the formatting structure of the code I have been working on:

QString errorName - the name of the error
QString description - a description of the error
QStringList causes - a list of possible causes of the error
QStringList solutions - a list of possible solutions for the error
QString techName - if not null, the more technical name for the error

If we wanted a slave's custom error to look the same if/when this is turned on 
for 3.1, we could:

1) add a new method to SlaveBase as below. If this breaks runtime 
compatability (I don't know) this would prevent kde2 apps from being able to 
use kde3 ioslaves; however it would be a much cleaner api:

void customError(const QString& errorName, const QString& description, const 
QStringList& causes, const QStringList& solutions, const QString& techName = 
QString::null)

2) require the QString errorText that is passed with the current error call to 
be a QByteArray which has had the above objects streamed in, and then pull 
them out at the other end.

Either of the above options would enable slaves to deliver error messages in a 
nice format, and for them to provide detailed and accurate assistance to the 
user.

Thoughts?

Hamish
[prev in list] [next in list] [prev in thread] [next in thread]