Ĉapitro 8. Mesaĝoj pri eraroj

Nikolay (unDEFER) Krivchenkov

2009-07-12

Unu el plej gravaj eroj de oportuna interfaco de ĉiu malsimpla aplikaĵo estas mesaĝoj al uzanto. Inter ili estas mesaĝoj pri eraroj. Kaj bedaŭrinde ĝuste ili ofte troviĝas kiel nekompreneblaj.

Ofte programistoj lasas mesaĝojn pri eraroj en la aspekto komprenebla nur al ili mem. Videble en espero, ke uzanto neniam ilin ne ekvidos.

Precipe estas teruraj mesaĝoj pri eraroj kiel: "eraro #XXXX".

Ĝenerale krom simple nekompreneblaj mesaĝoj pri eraroj ekzistas almenaŭ du ekzemploj de tipaj metodoj de erartrakto, kiuj ne donas sufiĉan informacion pri ĝi:

  1. Se ekzistas tri kondiĉoj a, b kaj c, kiu devas plenumi samtempe ekzistas granda logo uzi sekvan kodon de trakto:

    if ( ! (a && b && c) ) { /*La eraro*/ ... }

    Unuige tri diversajn variantojn de eraro en unu. Rezulte uzanto ne povos ekkoni laŭ erarmesaĝo, kio ĝuste ne tiel. Kaj se li ne estas programisto kaj ne povas aldoni testojn laŭ neceso, tiam la sola ebleco ĝustigi estas elekti enigajn datumojn tiel, ke provi ĉiun tri eblajn variantojn.

  2. Se funkcio a() vokas funkcion b(), en kiu okazas eraro, tiam ofte mesaĝon pri eraro oni skribas nur en unu el ĉi tiuj funkcioj. En ĉiu okazo aperas nepleneco de mesaĝo pri eraro. Ekzemple "Ĉe malfermo de dokumento okazis la eraro" sen ĝustigo kiu ĝuste estas la eraro, aŭ inverse "Ĉe sintaksa analizo estas trovita ne allasebla signo" sen ĝustigo kial la dokumento estis necesa.

Kio ajn ĝi estis neplenaj mesaĝoj pri eraroj kondukas al grandegaj perdoj da tempo de uzanto. Por mi mem estis la tre memorfiksita okazo, kiam mi pro negranda eraro en sintakso de dosiero por mysql perdis duontago por serĉo ĝin. Tiuokaze mem interpretilo mysql certe "sciis" en kio ĝuste la eraro, sed donis al mi multe pli ĝeneralan priskribon.

Mi tre volus, ke ĉiu programisto leganta la teksto memorfiksis: ĉia bagatelo en programo kondukanta al perdo de homo da pli ol 5 minutojn absolute sen progresado estas cimo de interfaco kaj postulas korekton. Uzantoj siavice devas raporti pri tiuj siaj perdoj da tempo kiel pri cimoj.

En idealo sistemo devas asigni maksimume plenan informon pri ĉia eraro kaj vojoj de forigo ĝin. Krome la informacio devas esti havebla sen retaliro aŭ aliro ĉian reton.

Certe ĉiu tiuj pensoj devas esti neapartigebla parto de koncepto unDE.

SourceForge.net Logo