[Development] Avoid overloading of 'error'

[Alan Alpert]

On Thu, Jun 11, 2015 at 7:11 AM, Hausmann Simon
<Simon.Hausmann at theqtcompany.com> wrote:
> Hi,
>
> I agree about the inconsistency in tense, that is a good argument against error(),
> although it is similarly unfortunate that the inconsistency in tense is more widespread than
> assumed.
>
> I'm not sure onErred or onErrored is any better, to be honest. I think it's more likely
> to result in a typo than the most basic form of the word - error - instead of some conjugation.
>
> In the light of that I think I'd prefer onFailed or onFailure - but I think it would perhaps be
> a mistake to make our existing APIs more inconsistent than necessary. It seems like an
> unfortunate choice, but I think it's better to stick to error() than to have some QML types
> have onError and some have onFailure.

I strongly advocate against replacing onError with onFailure. The
issue as I see it is a conflict between classic (perhaps BASIC
derived?) convention of handlers being "on" + <state noun> versus our
convention of "on" + <past tense verb>. Failure, Error (and success,
completion etc.) are all the old convention so it's not worth moving
from Error just to another word in the same convention that we're
trying to escape from. I also don't like to conceptually pin error to
failure, because in rare cases you can still have a partial success
despite an error condition.

Since there is this other convention that uses "onError" a lot (at
least in XMLHttpRequest), I can see how a similar (but past tense)
word would be confusing to many developers. So now we're weighing the
cost of confusing both new and old developers just to make the
refactoring support work better. I'm no longer convinced it's
worthwhile, so I'm with Simon on that it's better to stick to error()
for now. At least for the QML exposed APIs.

> If I break out the thesaurus, then we also have
>
>       errorBefell

If we want to sound fancy, we can use an obscure language and then it
can be shorter too: tokFeil . Also solves the problem of looking like
other APIs, as they limited themselves to English.

--
Alan Alpert