sitter added a comment.
Hm. I've had a quick look and I think the intent was that only the slavebase
overridden functions call error or finished. So technically all internal
functions that can have an error need to set an iError or return one so that
the "public" function can then issue error() as needed. This seems to not very
well enforced and probably never was, in fact there's a comment in the .h about
this very fact
// ------------------------------------------------------------------------
// All the methods named ftpXyz are lowlevel methods that are not exported.
// The implement functionality used by the public high-level methods. Some
// low-level methods still use error() to emit errors. This behaviour is not
// recommended - please return a boolean status or an error code instead!
// ------------------------------------------------------------------------
What I think may be best to resolve this is to split the class in two.
The "public" class only has overrides of SlaveBase. It's functions are the
only ones that may issue `error()` or `finished()`.
The "private" class has all the supporting functions and has no access to
SlaveBase so it cannot issue error or finished.
This should be a very durable solution as even in the future no one will
accidentally add another call to error or finished in one of the internal
functions since they are in a different object and all error handling must be
done via iError or some other system.
In fact, I am thinking this is a case where one could just use exceptions.
The private class could throw a simple exception on errors and in the public
class we'd need nothing more than a try{}catch in all the public functions.
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D22528
To: ZaWertun, sitter, dfaure, cfeck
Cc: kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns
