[Development] Avoid overloading of 'error'

[Kurt Pattyn]

Well,

you can also think of “on” + <event>, like in: onWindowClosed, onMouseClicked, onBytesReceived, …
In the same analogy, you could have onErrorOccurred.

Seems very intuitive to me.

It depends if you want to react to a state or to the event causing that state.

Cheers,

Kurt

> On 11 Jun 2015, at 20:29, Alan Alpert <416365416c at gmail.com> wrote:
> 
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development