vai leitot RETURN vai tomēr ne (diskusijas turpinājums)

[codez]

@php newbie, Ir reāli, ir. Tiek darīts ne vienā vien projektā un ne pirmo gadu... Un arī ne gadu desmitu.

 

Turpini vien rakstītu savu spagetī kodu, others don't care.

Un pēdejie pāris codez komentāri ...

bla, bla, bla...

Saka cilvēks, kurš pats nespēj/nevar parādīt labāku risinājumu ar savām metodēm.

[Mr.Key]

Izņēmumsituācijas ir dažādas, par to MS piemēru runājot, man tā izskatās pēc pārbaudes, vai sistēmas dati ir korekti. Vienkāršs piemērs:

 

 

// Kāda datubāzes modeļa kaut kāda metode:
 
$rows = $dataTable->find($id);
if (count($rows) == 0) {
    // Nav atrasts
    // Web aplikācijas GET gadījumā nav exception
    // Bet IR Exception, ja tas ir kodā, kur zināms, ka $id ir tikai reāli eksistējoši DB ieraksti.
    // Un to izlemj metode, kas izsauc (kontrolierī, citā modelī), tāpēc te tikai return.
    return false;
} elseif (count($rows) > 1) {
    throw new Company_Developers_Drunk_Exception('Kaut kas neticams, nav PK!');
}
 
// Normālais gadījums
...

 

Tādejādi, piemēram, ja lido ārā Exception, tad ir skaidrs, ka sistēmā kaut kas darbojas nepareizi, darbība neraisa uzticību un situācija prasa izpēti. Un, visticamāk, programmas labojumu. Iespējams - apkārtrisinājumu, izveidojot programmatisku rīcību, ja zināms, kas jādara kāda konkrēta Exception gadījumā.

 

Tāpēc arī negribētos biznesa loģikai izmantot Exceptions, jo jau pašā sākumā ir zināms, kā jārīkojas katrā situācijā un ka būs jārīkojas, jo neatstās taču tā, ka sistēma izvada pircējam rezultātu "Sistēmas kļūda: nepietiekams preces atlikums. Gadījumā, ja kļūda atkārtojas, lūdzam sazināties ar tehnisko dienestu."

Edited March 11, 2013 by Mr.Key

[F3llony]

Labi Microsoft nav tas labākais piemērs. Ir redzēts ļoti slikts kods.

 

Bet nu labi. MS koda piemēri(nav webs):

 

 

protected void checkBeforePosting()
{
    if (salesParmLine.RemainBefore     != (salesLine.RemainSalesFinancial + salesLine.RemainSalesPhysical)||
        salesLine.RemainInventPhysical != salesParmLine.RemainBeforeInventPhysical)
        throw error("@SYS23025");
}

tad arī kur to izsauc:

 

 

            // If the tax codes are to be verified, check if sales tax id and Item tax id
            // are defined per line.  If the ledger account requires a tax code, and tax code
            // is not provided, the posting will be stopped.
            if (taxParameters.ValidateTaxCode)
            {
                postingLedgerTable = LedgerTable::find(
                    InventPosting::accountItem(InventAccountType::SalesRevenue,
                            salesLine.ItemId,
                            inventTable.ItemGroupId,
                            salesLine.CustAccount,
                            salesLine.CustGroup,
                            salesLine.TaxGroup ));

                if (!this.tax().checkNoTax(postingLedgerTable,
                                            salesLine.TaxGroup,
                                            salesLine.TaxItemGroup))
                {
                    throw error("@SYS21533");
                }
            }

            this.checkBeforePosting();

un tt.

 

 

 

That is just... wrong :( Lai gan nezinu, vai pirms tam nav datu validācijas, varbūt tax code neesamība arī ir anomālija. Maz man bijis dīls ar axaptu. 

 

Diezgan normāla parādība Oracle PL/SQL:

DECLARE
  testVal INTEGER;
BEGIN
  SELECT 1
    INTO testVal
    FROM some_table
    WHERE field='const';
  RETURN TRUE;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    RETURN FALSE;
END;

 

T.i. normāls veids, kā pārbaudīt vai ieraksts eksistē (ar COUNT(*) būs lieks pieprasījums SQL serverim).

Nē, nav normāla. No data found pilnīgi noteikti nelieto lai skaitītu vai pārbaudītu rowa eksistenci. Vismaz es šādu pieeju pirmo reizi redzu. Es šajā keisā izmantotu select case when exists. 

[zuks]

DECLARE
  testVal INTEGER;
BEGIN
  SELECT 1
    INTO testVal
    FROM some_table
    WHERE field='const';
  RETURN TRUE;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    RETURN FALSE;
END;

 

Ja es kaut ko tādu izmantotu būvejot savas pakotnes (funkcijas, procedūras) web developeri mani izmestu aiz durvīm vienīgais variants ko es pieņemu ar No Data Found ir raise application error lai apstājas pilnīgi viss process ar backtrace uz iemeslu 

[nemec]

Tāpēc arī negribētos biznesa loģikai izmantot Exceptions, jo jau pašā sākumā ir zināms, kā jārīkojas katrā situācijā un ka būs jārīkojas, jo neatstās taču tā, ka sistēma izvada pircējam rezultātu "Sistēmas kļūda: nepietiekams preces atlikums. Gadījumā, ja kļūda atkārtojas, lūdzam sazināties ar tehnisko dienestu."

 

Nu ja aizmirsi apstrādāt šo izņēmumu, tad lai labāk met tādu lietotājam. No otras puses, ja tie ir IFi, tad šo kļūdu jau būs problemātiski atrast (lietotājs nevarēs nopirkt, bet kāpēc tad ej un meklē kodā, jo kāds aizmirsta apstrādāt šo situāciju).

 

Man ir tā, ka uz katras kļūdas nāk e-pasts (gan python, gan javascripts) un tad eju labot. Lai lietotājs paskatās uz 500. kļūdu, toties es momentā noreaģēšu (piemēram uz NotAuthorized kādā vietā).

 

Protams, ka ir arī supermeni, kuri spēj paredzēt visas tādas situācijas. Es tā neprotu, tāpēc labāk neriskēšu, jo sliktākajā gadījumā vajadzēs sēdēt un nodarboties ar atkļūdošanu. Savukārt atkļūdošanas process man ļoti nepatīk un mēģinu no tā izvairīties.

[codez]

Tātad, visiem exceptionu lietošanas noliedzējiem ieteiktu iepazīties ar:
1)Saturu no grāmatas "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices"
http://www.icodeguru.com/cpp/CPPCodingStandardsLiB/art01lev1sec9.html

 

Grāmatas viens no autoriem: "Andrei Alexandrescu is a Romanian C++ programmer and author. He is particularly known for his pioneering work on policy-based design implemented via template metaprogramming. Alexandrescu is currently a research scientist at Facebook."

 

 

72. Prefer to use exceptions to report errors.

When harmed, take exception: Prefer using exceptions over error codes to report errors. Use status codes (e.g., return codes, errno) for errors when exceptions cannot be used (see Item 62), and for conditions that are not errors. Use other methods, such as graceful or ungraceful termination, when recovery is impossible or not required.

 

2) When and How to Use Exceptions
Šī raksta un iepriekšējās grāmatas autors: Herb Sutter (http://www.gotw.ca/) is a leading authority and trainer on C++ software development. He chairs the ISO C++ Standards committee and is a Visual C++ architect for Microsoft, where he is responsible for leading the design of C++ language extensions for .NET programming

 

no raksta:

 

The summary: A function is a unit of work, and failures should be viewed as errors or otherwise based on their impact on functions. Within a function f, a failure is an error if and only if it prevents f from meeting any of its callees' preconditions, achieving any of f's own postconditions, or reestablishing any invariant that f shares responsibility for maintaining.

 

Tātad, funkcijā kļūda ir:

1) nespēja nodrošināt tās izsaucēja priekšnosacījumus,

2) nepsēja sasniegt funkcijas izpildāmos mērķus (pēcnosacījumus),

3) nespēja nodrošināt invariantu, par kura uzturēšanu tā ir atbildīga.

 

Smalkāki paskaidrojumu par katru no gadījumiem ir aprakstīti rakstā.

Bet, tagad apskatīsim manu piedāvāto variantu.

Ir kontroleris, kuru izsaucot ir jānotiek itema pirkumam.

 

 

 

class Account extends Controller{
  function buy(){
    $itemid=Reuqest::post('itemid','int');
    $amount=Request::post('amount','int',array('min'=>1,'max'=>10000));
    $item=Model_Item::get($itemid);
    $account=Model_account::auth();
    $account->decMoney($item['price']*$amount);
    $account->addItem($itemid, $amount);
    db::commit();
  }
} 

 

Tātad, kontrolera account akšans buy ir funkcija - "unit of work" - tās mērķis (postconditions) ir veiksmīgi nodrošināt pirkumu, noņemot no accounta naudu un pieliekot accountam itemu. Jebkura nespēja veikt šo uzdevumu ir uzskatāma par kļūdu, bet kļūdas labākais kontroles mehānisms ir izsaukt eksepšanu.

Tālāk seko 2 līdzīgi izsaukumi:

$itemid=Reuqest::post('itemid','int');
$amount=Request::post('amount','int',array('min'=>1,'max'=>10000));

Request::post ir funkcija - "unit of work", kuras mērķis ir atgriezt POST datus un nodrošināt, lai tie ir ar noteiktu tipu un noteiktā intervālā.

Jebkurš iemesls, kura dēļ šī funkcija nevar nodrošināt savus pēcnosacījumus (postcondition) ir uzskatāms par kļūdu.

Tātad, ja POST mainīgais nav, saucam eksepšanu, ja postmainīgais nav vesels skaitlis, saucam eksepšanu, 2. gadījumā ja post mainīgais nav robežās no 1 - 10000, saucam eksepšanu. Jo visas tās ir funkcijas kļūdas - nespēja nodrošināt tās (postcondition).

 

Tālāk,

$account=Model_account::auth();

Funkcijas Model_account::auth() - "unti of work" - mērķis ir atgriezt autorizētā lietotāja kontu. Jebkura nespēja šo pēcnosacījumu (postcontition) nodrošināt ir uzskatām par kļūdu un pēc labākas prakses ir apstrādājama ar eksepšaniem.

Tātad, ja lietotājs nav ielogojies, metam eksepšanu, ja lietotāja accountu pēkšņi nevar ielādēs, piemēram lietotājs ar tādu id ir izdzēsts, vai ir db konekcijas kļūda, metam eksepšanu.

 

Tālāk,

$account->decMoney($item['price']*$amount) ir funkcija - "unit of work", kura mērķis (postcondition) ir samazināt kontā naudu par doto daudzumu. Ja funkcija nespēj nodrošināt savu "postcondition", metam eksepšanu, kas būs gadījumā, ja kontā naudas nepietiek.

 

Nākošā tēma ir kad un kā pārķert šos eksepšanus. Viens no pamatlikumiem ir:

 

throw early catch late

 

 

Tātad, ja kļūda ir tāda, ko būtu vērts paziņot lietotājam (lai viņš nebūtu pilnīgā neziņā, kāpēc kaut kas nestrādā), to pārķer FC un veic pieprasījuma nodošanu kļūdas paziņošanai lietotājam. Ja kļūda ir dziļi sistēmiska, piemēram, nav konekcija ar db, tad tiek izvadīts defaultais kļūdu ziņojums par sistēmas nestrādāšanu, visos vai dažos (pēc vajadzības) gadījumos attiecīgie eksepšani tiek logoti.

 

Ceru, ka F3llony šodien kaut ko jaunu iemācījās (Protams pastāv arī iespēja, ka F3llony nepiekritīs arī cilvēku, kuri ir valodu un programmēšanas standartu izveidošanas augšgalā un ir best practice guru, viedoklim).

 

P.S. Un jā, F3llony, drīksti turpmāk mani dēvēt par senseju.

 

Edited March 11, 2013 by codez

[F3llony]

Es pilnīgi piekrītu augstāk minēto autoru viedoklim. Es nepiekrītu tavai šo rakstu interpretācijai, un pieņemu, ka arī paši autori ne. 

 

1. Andreijs Aleksandresku ir lielisks cilvēks un izcils speciālists, man ļoti patīk viņa darbs pie D valodas kopā ar vēl vienu lielisku programmētaju un speciālistu - Valteru Braitu. C++ 101 esmu izlasījis no vāka līdz vākam, divreiz. Tur nav neviena vārda par to blamāžu, ko tu te perini. 

 

P.S. Facebook ir jauka vieta, ja patīk čakarēties ar "business & marketing before technology" vai arī esi ADP izredzētais. Piedāvāja man tur darbu. Divreiz. Nu ja jau tu to tik ļoti izcel...

 

2. Tev smadzeņpods par šauru lai vispār spētu uzsūkt kaut 5% no tā, ko ar to gribēja pateikt Herb Sutter. Cita starpā, viņš lielu daļu savas prakses ir pavadījis apgaismojot tādus idiotus, kā tevi. Diemžēl, arī karojot pret nepareizu viņa teiktā interpretāciju. 

 

3. Throw early, catch late ir Javas un citu VM/CLR ne-lineāru, konkurentu valodu specifisks koncepts, kuru attiecināt uz lineārām valodām var tikai nekompetents stulbenis. Pie tam, tavā gadījumā vispār izrauts no konteksta un pielietots bezjēgā -"throw early, catch late, but not too late - only when the problem can be solved" ir pilns koncepts. 

 

Izņēmumus neizvada lietotājam, izņēmumus atrisina! Tieši tāpēc šī konstrukcija nav fatalistiska - normālā gadījumā Exception nekad nenonāk pie lietotāja (NEKAD as in NEVER) bet tiek handlots - exception handling ir veids, kā recoverot anomālas situācijas ne pretty printot kļūdu paziņojumus. Tad jau bļg vienkārši met errorus vai killo trīdus ar eksotiskiem exit statusiem, kam tev vēl izņēmumi? Sliktākajā gadījumā - 500 un izņēmums tiek ielogots lokālā/centrālā logā. Da i vispār iemācies atšķirt kļūdu, izņēmumu un steitu. Nevis mauc visus konstruktus vienā maisā. 

 

Ceru, ka apmeklēsi ārstu. 

 

Sensejs... Vantuza operators... 

 

P.S. Es laikam esmu morāls mazohists. Tas pats, kas pārliecināt 6. gadsimta mācītāju, ka Zeme tomēr nav universa centrs.

 

P.P.S. 

 

lietotājs ar tādu id ir izdzēsts

WAT?

Edited March 11, 2013 by F3llony

[zuks]

Saglabājam pirkuma info - automatizēti  izveidojam tranzakciju ar attiecigajām summām un nepieciešajām pazīmēm , Gala procedūra nolasa visu info un updeito accounts . Piemēram  gala procedūra 5 iespējamas apstrādes tās kuras paši pirms tam uzskaitījāt n tajā lapā.  Bļin ko es te meklēju te tak ir php :D 

 

 

DB puse Exception patērē tik daudz resursu, ka labāk ir kaut vai zarot , pat lielajos feetchos ar pārīti atvērtiem kursoriem . 

Edited March 11, 2013 by zuks

[codez]

C++ 101 esmu izlasījis no vāka līdz vākam, divreiz.

Nepietiek izlasīt, vajag saprast un atcerēties.

Ja saprastu un atcerētos, nerakstītu tādas muļķības, kā tagad raksti - piemēram, par haltošanu ar exit kodiem.

Es pilnīgi piekrītu augstāk minēto autoru viedoklim. Es nepiekrītu tavai šo rakstu interpretācijai, un pieņemu, ka arī paši autori ne.

Es neinterpretēju, es iztulkoju un tiešā veidā pielietoju tulkojumu. Ja redzi manā tulkojumā vai tā pielietojumā neprecizitātes, vari droši paskaidrot, kāds ir tavs viedoklis šajā sakarā.

Visā garajā diskusijā, tu vēl neesi izteicis nevienu savu viedokli par to, ka būtu labāk darīt.

2. Tev smadzeņpods par šauru lai vispār spētu uzsūkt kaut 5% no tā, ko ar to gribēja pateikt Herb Sutter. Cita starpā, viņš lielu daļu savas prakses ir pavadījis apgaismojot tādus idiotus, kā tevi. Diemžēl, arī karojot pret nepareizu viņa teiktā interpretāciju.

Lūdzu, tev ir visas iespējas izteikt savu "pareizo" interpretāciju, vai arī norādīt, kas tavuprāt manā viņā teiktā tulkojumā ir nepareizs.

3. Throw early, catch late ir Javas un citu VM/CLR ne-lineāru, konkurentu valodu specifisks koncepts, kuru attiecināt uz lineārām valodām var tikai nekompetents stulbenis. Pie tam, tavā gadījumā vispār izrauts no konteksta un pielietots bezjēgā -"throw early, catch late, but not too late - only when the problem can be solved" ir pilns koncepts.

Nē, šis koncepts attiecas uz visām valodām, kurās ir eksepšanu mehānisms.

Izņēmumus neizvada lietotājam, izņēmumus atrisina!

Tieši tā, manā piemērā visi doti izņēmumi tiek atrisināti ar labāko iespējamo variantu.

Piemēram, ja pazudusi db konekcija, tad labākais iespējamais variants ir nevis haltot pieprasījuma izpildi, bet gan paziņot lietotājam, ka ir tehniskas problēmas.

Labākais iespējamais risinājums, ja nevar izpildīt pirkumu, ir paziņot lietotājam, ka viņam trūkst nauda, nevis haltot pieprasījumu.

Es ceru, ka tik elementāras lietas tu izproti?

Tieši tāpēc šī konstrukcija nav fatalistiska - normālā gadījumā Exception nekad nenonāk pie lietotāja (NEKAD as in NEVER) bet tiek handlots - exception handling ir veids, kā recoverot anomālas situācijas ne pretty printot kļūdu paziņojumus.

Jā tieši tā, "normālā" gadījumā konkrētajā pieprasījumā leitotājs ir ielogots, nauda pirkumam pietiek, un inventorijā ir pietiekami vietas, visi post mainīgie tiek padoti un datubāzes konekciju ir iespējams izveidot.

Manā piemērā, "normālā" gadījumā tiešām nenotiks eksepšana izsaukšana.

Tad jau bļg vienkārši met errorus vai killo trīdus ar eksotiskiem exit statusiem, kam tev vēl izņēmumi? Sliktākajā gadījumā - 500 un izņēmums tiek ielogots lokālā/centrālā logā.

Tieši tāpēc jau izņēmumi vajadzīgi, lai nebūtu jākillo viss un varētu apstrādāt izņēmuma gadījumus.

Bet šī koncepcija tev varētu būt jauna, tāpēc sākumā uzreiz grūti uztverama.

Ceru, ka apmeklēsi ārstu.

Skatos, ka tavs superuzpūstais ego ārdās, jo tev nav taisnība, bet nevēlies to pieņemt, tāpēc vienīgais, kas atliek ir neargumentēti lamāties.

P.S. Es laikam esmu morāls mazohists. Tas pats, kas pārliecināt 6. gadsimta mācītāju, ka Zeme tomēr nav universa centrs.

Lai kaut censtos pārliecināt, ir jāpasaka, kāds ir tavs variants. Pagaidām tu tikai ar lamāšanos saki, ka es esmu idiots un, ka man nav taisnība, bet savu variantu vēl neesi piedāvājis.

[codez]

 

P.P.S.

lietotājs ar tādu id ir izdzēsts

WAT?

 

Redz, tu pat nespēj par visām situācijām iedomāties, bet eksepšanu gadījumā nav jāiedomājas. Ja būs anomālija, tad atbildīgā vieta izmetīs eksepšanu un sliktākajā gadījumā lietotājs saņems paziņojumu par tehnisku kļūmi, nevis aplikācijas mēģinās veikt absurdas darbības.

Tātad, kā šāda situācija var rasties.

1) Lietotājs atver tabu, kurā ir pirkums.

2) Lietotājs atver otru settingu tabu, kurā ir konta dzēšana. Tā kā, piemēram, likumdošana nosaka, ka lietotāja datus paturēt nedrīkst (piemēra situācija), konts jādzēš.

3) Izdzēš kontu 2. tabā.

4) Taisa pirkumu 1. tabā.

[F3llony]

I should probably stop trying just about now... 

 

 

 

 

 

 

[Mr.Key]

Nu ja aizmirsi apstrādāt šo izņēmumu, tad lai labāk met tādu lietotājam. No otras puses, ja tie ir IFi, tad šo kļūdu jau būs problemātiski atrast (lietotājs nevarēs nopirkt, bet kāpēc tad ej un meklē kodā, jo kāds aizmirsta apstrādāt šo situāciju).

 

Tas, kā šī lieta varētu praktiski realizēties, ir Exception, ko izraisa datubāzes nosacījumu (constraints, rules) neizpildīšanās. Ja domā programmā veidotus nosacījumus, kas izmet Exception gadījumam, ja šie nosacījumi tiek aizmirsti, tad tas tā interesanti sanāk. Un ja nu aizmirsīsi izveidot nosacījumu, kas izmet Exception gadījumiem, ja tiek aizmirsti nosacījumi? :-)

[codez]

I should probably stop trying just about now... 

Pats bēdīgākais, ka tu vēl pat neesi sācis. Visā šajā garajā postā nav neviena tava piedāvāta reāla risinājuma, ja neskaita to, kurā ir bezgalīgais cikls. Nemaz nerunājot par to, ka tu neesi aprakstījis nevienu alternatīvu praksi līdzīgu problēmu vispārīgai risināšanai.

[Mr.Key]

Redz, tu pat nespēj par visām situācijām iedomāties, bet eksepšanu gadījumā nav jāiedomājas. Ja būs anomālija, tad atbildīgā vieta izmetīs eksepšanu un sliktākajā gadījumā lietotājs saņems paziņojumu par tehnisku kļūmi, nevis aplikācijas mēģinās veikt absurdas darbības.

Tātad, kā šāda situācija var rasties.

1) Lietotājs atver tabu, kurā ir pirkums.

2) Lietotājs atver otru settingu tabu, kurā ir konta dzēšana. Tā kā, piemēram, likumdošana nosaka, ka lietotāja datus paturēt nedrīkst (piemēra situācija), konts jādzēš.

3) Izdzēš kontu 2. tabā.

4) Taisa pirkumu 1. tabā.

Šādā situācijā 4. punktā būtu jābūt "Neesi autorizējies", ja vien tā forma nez kapēc hidden datos padod lietotāja ID tā vietā, lai lietotāju noteiktu pēc sesijas ID. Exception varētu izlido tad, ja pirkumu taisa lietotāja dzēšanas laikā un pieprasījuma sākumā lietotājs vēl nav izdēsts, bet, kodam nonākot līdz tranzakcijas uzsākšanai, lietotājs jau ir izdzēsts.

 

Te arī rodas jautājums, vai tad, kad kods, kurš pieņem, ka lietotājs ir autorizējies un eksistē, tiek veikts pirkums, iespēja, ka klients vairs neeksistē, ir izņēmums (metam Exception), vai daļa no biznesa loģikas (redirect uz login lapu)? Vai tas tiek realizēts programmas kodā vai datubāzē? Ja datubāzē ir pilns ar nosacījumiem, vai tos dublēt kodā (negribētos), jeb kodā uzķert DB Exception? Utt.

Edited March 11, 2013 by Mr.Key

[codez]

Tas, kā šī lieta varētu praktiski realizēties, ir Exception, ko izraisa datubāzes nosacījumu (constraints, rules) neizpildīšanās. Ja domā programmā veidotus nosacījumus, kas izmet Exception gadījumam, ja šie nosacījumi tiek aizmirsti, tad tas tā interesanti sanāk. Un ja nu aizmirsīsi izveidot nosacījumu, kas izmet Exception gadījumiem, ja tiek aizmirsti nosacījumi? :-)

Bet tur jau tā lieta, ka ievietot šo pārbaudi zemākajā līmenī un vienu reizi ir daudz vienkāršāk un ar daudz mazāku iespēju, ka tas tiks aizmirsts.

Piemēram, ievietot, vai lietotājs ir autorizējies, vietā, kur tiek pieprasīts autorizēts lietotājs. Parbaudīt vai nauda pietiek, vietā, kur tā tiek noņemta. utt.

Tālāk, lai cik vietās tev vajadzētu pēc tam autorizētu lietotāja kontu, vai noņemt naudu, tev šī pārbaude jau būs. Pat elementārās darbībās var būt desmitiem dažādu iemeslu, kāpēc konkrētā darība nevar tikt izpildīta, ja katrai darbībai tiks rakstītas pārbaudes visiem šiem iemesliem, agri vai vēlu, kāda pārbaude tiks aizmirsta un noteiktos apstākļos tiks izpildītas darbības, kuras nedrīkstēja pildīt.

 

Šādā situācijā 4. punktā būtu jābūt "Neesi autorizējies", ja vien tā forma nez kapēc hidden datos padod lietotāja ID tā vietā, lai lietotāju noteiktu pēc sesijas ID.

Piemēram, dzēšot kontu, netika izdzēsta sesija. Tas ir piemērs, mazvarbūtīgs, pat uzskatāms par bugu. Bet šeit nav runa par procentuālo varbūtību kā tādu, bet gan par principu - par to, ka tas teorētiski ir iespējams un katrai darbībai uzrakstīt visus iespējamos pārbaudes nosacījumus un to daudzās kombinācijas ir sarežģīti un tā ir reāla vieta kļūdām.