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

[Mr.Key]

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.

 

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.

Jā, jautājums, kā nodalīt atbildību par to, kurš veic šo pārbaudi?

Viens variants ir modeļos, taisot tight-coupling. Cits variants ir FC + ACL, kas nodrošina, ka attiecīgās kontrolieru metodes ir pieejamas autorizētam lietotājam. Bet, piemēram, batch skripts, kurš ielādē pasūtījumus, kas tiek novilkti CSV failā no citas sistēmas, varētu negribēt nekādu autorizācijas pārbaudi, neskaitot to, ka tiek nodrošināta šī avota uzticamība. Autorizācijas pārbaude modeļos vairs nebūs tik ērta, ne tā?

[Mr.Key]

Piedāvāja man tur darbu. Divreiz. Nu ja jau tu to tik ļoti izcel...

Nākas skumji atzīt, ka man nav piedāvāts nevienu reizi... :-( Vai tas bija tā, ka ja teiktu "jā", tad uzreiz parakstītu līgumu un piedāvātāji nebija rekrūteri?

[codez]

Jā, jautājums, kā nodalīt atbildību par to, kurš veic šo pārbaudi?

Viens variants ir modeļos, taisot tight-coupling. Cits variants ir FC + ACL, kas nodrošina, ka attiecīgās kontrolieru metodes ir pieejamas autorizētam lietotājam.

FC + ACL protams glābs situāciju ar autorizētu lietotāju, bet tas it tikai viens no desmitiem izņēmumu, kuri var notikt.

Tālāk nāk neesoši post dati, neatbilstoši post dati, konekcijas problēmas ar db, utt.

Bet, piemēram, batch skripts, kurš ielādē pasūtījumus, kas tiek novilkti CSV failā no citas sistēmas, varētu negribēt nekādu autorizācijas pārbaudi, neskaitot to, ka tiek nodrošināta šī avota uzticamība. Autorizācijas pārbaude modeļos vairs nebūs tik ērta, ne tā?

Manā piemēra es izmantoju funkciju, kura atgriež autorizētā lietotāja kontu. Šī funkcija veic šo pārbaudi, jo tās uzdevums ir atgriezt autorizētā lietotāja kontu un, ja lietotājs nav autorizējies, tā nespēj izpildīt savu "postcondition", tāpēc met eksepšanu.

Gadījumā ar CSV faila importu, netiks izsaukta funkcija, kura pieprasa autorizētu lietotāju, bet, piemēram, lietotājs tiks ielādēts pēc id, kā gadījumā šāda pārbaude nebūs, jo ielādei pēc id, neautorizēts lietotājs netraucē "postcondition" izpildi un līdz ar to šī funkcija eksepšanu neizsauks.

[codez]

 

Piedāvāja man tur darbu. Divreiz. Nu ja jau tu to tik ļoti izcel...

 

Nākas skumji atzīt, ka man nav piedāvāts nevienu reizi... :-( Vai tas bija tā, ka ja teiktu "jā", tad uzreiz parakstītu līgumu un piedāvātāji nebija rekrūteri?

Tak viņam piedāvāja uzreiz Facebook CEO amatu, tik nāc un vadi, nemaz nerunājot, par to, ka viņam lūdzās, lai viņš pārņem Apple vadību pēc Stīva nāves.

[F3llony]

Nākas skumji atzīt, ka man nav piedāvāts nevienu reizi... :-( Vai tas bija tā, ka ja teiktu "jā", tad uzreiz parakstītu līgumu un piedāvātāji nebija rekrūteri?

Neskumsti, mums ir arī interesantākas lietas, kā FB. Piemēram Google. :D Jā, ja būtu piekritis gan jau pašlaik rakstītu no otras planētas puses.

Tak viņam piedāvāja uzreiz Facebook CEO amatu, tik nāc un vadi, nemaz nerunājot, par to, ka viņam lūdzās, lai viņš pārņem Apple vadību pēc Stīva nāves.

Anonīmi internetā dirst prot katra mājsaimniece. Ej, uztaisi vīram pusdienas.

[codez]

Neskumsti, mums ir arī interesantākas lietas, kā FB. Piemēram Google. :D Jā, ja būtu piekritis gan jau pašlaik rakstītu no otras planētas puses.

Zināju, ka Google uztur savu ēdināšanas sistēmu un pat algo pavārus, bet nezināju, ka viņiem ir arī savs cirks.

Anonīmi internetā dirst prot katra mājsaimniece. Ej, uztaisi vīram pusdienas.

Pagaidām vienīgais plikai d.... esi tu, jo tu esi vienīgais, kuram šeit ir viedoklis, ka visi citi ir idioti un dara nepareizi, bet nav viedokļa par to, kā būtu jādara pareizi. Pie tam šī nav vienīgā diskusija, kur tu visu noliec, bet pateikt savu "viedo" alternatīvu nespēj.

[F3llony]

Visi citi? Neviens, izņemot tevi, šajā topikā vēl nav paspējis kvalificēties idiota statusam. Tu paspēji jau vairākas reizes. 

 

Man nav viedokļa? Es tev jau reizes 5 esmu pateicis, kā ir pareizi, es nesaprotu kā man vēl tev būtu jāpaskaidro - moš uzrakstīt visu kodu tavā vietā? Pie tam, izskatās, ka lielais vairums tomēr sliecas piekrist man. Cik dīvaini... 

Edited March 12, 2013 by F3llony

[codez]

Vēl neeliela mācību stunda tiem, kuri ne pārāk orientējas eksepšanu lietošanā:
 
Atgriežamies vēlreiz pie precīzā definējuma, kas ir funkcijas kļūda un kad ir jāatgriež eksepšans.
http://www.drdobbs.com/when-and-how-to-use-exceptions/184401836

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, piemēram, ja mums ir funkcija - account metode isAuth - kura atgriež, vai dotais konts pieder autorizētam lietotājam, vai nē, tad situācijā, ja lietotājs nav ielogojies, funkcija tik un tā spēj veiksmīgi izpildīt savu nosacījumu - tas ir, atgriezt to, vai konts pieder autorizētam lietotājam. Šijā gadījumā eksepšans nav jāmet:

function isAuth(){
  if ($this['id']==Auth::id()) {
    return true;
  } else {
    return false;
  }
}

 

Taču, ja mums, piemēram, ir funkcija getAuth, kura atgriež autorizētā lietotāja kontu, tad tās uzdevums ir tieši tāds un, ja lietotājs nav autorizējies, tad funkcija nespēj izpildīt savu uzdevumu un nodrošināt 2. nosacījumu - "achieving any of f's own postconditions". Tātad šijā gadījumā tā ir funkcija kļūda un ir jāmet eksepšans:

static function getAuth(){
  $account=new self();
  if (Auth::is() and $account->loadById(Auth::id()) {
    return $account;
  } else { 
    throw ...
  }
}
 

 

Tālāk ielikšu pāris linkus par to kā, tai skaitā validācijai, eksepšani tiek izmantoti citās valodās vai līdzīgās situācijās.

http://www.javapractices.com/topic/TopicAction.do?Id=5

http://www.javapractices.com/topic/TopicAction.do?Id=129

http://stackoverflow.com/questions/3860037/throwing-exceptions-from-model-view-controller-in-a-zend-framework-application
http://docs.oracle.com/javaee/6/api/javax/validation/ValidationException.html

 

Tālāk iemetīšu linkus, kur var redzēt, ka pat top php freimworkos ir paredzēta kaudze exceptionu, sākot ar validācijas un nepareizi parametru vai opciju eksepšaniem:

http://framework.zend.com/apidoc/2.0/namespaces/Zend.Validator.html

https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Validator/Exception

http://kohanaframework.org/3.1/guide/api/Validation_Exception

 

P.S.

Šorīt man sieva prasa, ar ko es vakar visu nakti sarakstījos.

Es atbildu, ka diskutējam par to kā pareizi jāprogrammē.

Viņa saka, tu tik nestāsti visiem visu priekšā.

Patiesībā sava pareizā doma tur ir, bet mani interesē, cik ilgi vēl F3llony turēsies pie savas iedomu pasaules uzskatiem un kas ir spēcīgāks dzinulis viņā - veselais saprāts, vai viņa nenormālais ego, kurš kuru katru brīdi draud pārsprāgt. Man tiešām žēl to cilvēku, kuriem ir ar viņu jāstrādā vienā darba vietā (šķiet, ka agrākos topikos jau daži izteicās, ka tas ir neciešami).

[codez]

Man nav viedokļa? Es tev jau reizes 5 esmu pateicis, kā ir pareizi, es nesaprotu kā man vēl tev būtu jāpaskaidro - moš uzrakstīt visu kodu tavā vietā?

Tu maldies, vienīgais piemērs, kur tu rakstīji kā būtu jādara pareizi (un cik saprotu tā bija ironija), bija ar bezgalīgo ciklu. Iekopēt tavu vienīgo variantu - lūdzu:

F3llony piemērs par to kā būtu jādara pareizi:

 

 

<?php
//FC:
NotAuthenticated:
die('Please auth!');
InsufficientFunds:
die('You, sir, are out of cash');

//Contr.:
if($item->price > $account->balance){
goto InsufficientFunds;
}
 

 

 

 

Pie tam, izskatās, ka lielais vairums tomēr sliecas piekrist man. Cik dīvaini...

Vēl pirms simts gadiem lielais vairums domāja, ka dievs eksistē, vai tas pierāda, ka dievs esksistē?

Vēl pirms 2000 gadiem lielais vairums domāja, ka Zeme ir plakana.

Bez tam, kurš tad ir tas lielais vairums viens? divi? trīs cilvēki? Vari uzskaitīt kuri? Šijā forumā ir vismaz pāris simti kaut cik aktīvu lietotāju.

P.S. Bez tam, ja nebūtu tik akls pamanītu, ka šijā pašā diskusijā ir arī cilvēki, kuri atbalsta eksepšanu lietošanu.

Edited March 12, 2013 by codez

[F3llony]

Neviens no linkiem nav ne tuvu līdzīgs tavai interpretācijai. Atkal. Visi 4 pirmie linki validē argumentu atbilstību prasībām. Javapractice topiki vēlreiz pasaka to pašu, ko es tev esmu centies ieskaidrot visa topika garumā. Par PHP linkiem - tu nolinkoji zend validatoru? un? Tu redzi, ka no visām šīm klasēm tikai 6 ir izņēmumi? Un pārējās met izņēmumus tad, kad ir anomālas situācijas, piemēram, mēģina izvilkt neesošu db instanci. Tas pats ar Symfony un Kohanu. Da i bļin palasi taču, kur šie izņēmumi tiek lietoti un kam viņi tiek lietoti. 

 

P.S. Man patiešām žēl, ka pat savai sievai esi pamanījies iestāstīt, ka neviens bez tevis nu nekur un nekā, nevienu soli. Also, mana sieva ir tikai par to, lai es visu visiem "teiktu priekšā", tā pat, kā es. Zini, tā tēze par "noķer cilvēkam zivi, viņš būs paēdis dienu. Iemāci viņu makšķerēt - viņš būs paēdis visu mūžu" un tamlīdzīgi, nekam nederīgi morāles principi. :)

 

Un tev šķiet nepareizi. Ar mani strādāt ir ļoti viegli. Tie, kas ir strādājuši to var apstiprināt. Un ja vari atrast kaut vienu komentāru jēlkur internetā no kāda, kas ar mani patiešām ir strādājis, kas teiktu, ka ar mani strādāt ir neciešami, es publiski, videokameras priekšā notiešāšu savu cepuri. Deal? 

 

 

Par to tavu kodu - apsvēri domu izmantot divas getAuth() metodes - getAuthUser() un validateGetAuth() kur getAuthUser atgriež kontu vai null (null - nav konta), kur nepieciešams un validateGetAuth() pārbauda lietotāju un ja lietotāja nav, saglabā esošo soli un nosūta lietotāju autorizēties? Es darītu vēl vairāk - kontrolierī, kur nepieciešams auth invokētu validateGetAuth konstruktā vai pirms action invokēšanas pret ACL. Šādi

1. Viss, kas ir ACL atzīmēts kā aizsargāts ir aizsargāts bez liekas koda bakstīšanas katrā vietā un autorizācijas metodika ir pārizmantojama

2. Neviens nevar aizmirst validēt lietotāju, implying, ka neesi vienīgais, kas lieto sistēmu. 

3. Tiek nodrošināta normāla programmplūsma - startpoint->step->endpoint, jo validateGetAuth() ir endpoints vai avots? 

4. Nav problēmu ar kaudzi ifu. Nav kaudze ar try catch un izņēmumi netiek lietoti tam, kam tie nav jālieto. 

Edited March 12, 2013 by F3llony

[daGrevis]

> 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.

 

Tas ir tieši tas, kas man tā patīk eksepšenos. Attiecīgi, nevar aizmirst pārbaudīt kko un turpināt darbu!

[php newbie]

es te ņemos ar kohanu: http://kohanaframework.org/3.2/guide/orm/validation#automatic-validation

Bet tieši šāda izmantošana man nepatīk

edit: Apskatijos kas ar zend..
 

    /**
     * Returns a URI based on current values of the instance variables. If any
     * part of the URI does not pass validation, then an exception is thrown.
     *
     * @throws Zend_Uri_Exception When one or more parts of the URI are invalid
     * @return string
     */
    public function getUri()
    {
        if ($this->valid() === false) {
            require_once 'Zend/Uri/Exception.php';
            throw new Zend_Uri_Exception('One or more parts of the URI are invalid');
        }

        $password = strlen($this->_password) > 0 ? ":$this->_password" : '';
        $auth     = strlen($this->_username) > 0 ? "$this->_username$password@" : '';
        $port     = strlen($this->_port) > 0 ? ":$this->_port" : '';
        $query    = strlen($this->_query) > 0 ? "?$this->_query" : '';
        $fragment = strlen($this->_fragment) > 0 ? "#$this->_fragment" : '';

        return $this->_scheme
             . '://'
             . $auth
             . $this->_host
             . $port
             . $this->_path
             . $query
             . $fragment;
    }

Edited March 12, 2013 by php newbie

[F3llony]

> 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.

 

Tas ir tieši tas, kas man tā patīk eksepšenos. Attiecīgi, nevar aizmirst pārbaudīt kko un turpināt darbu!

Vai arī tu varētu pārbaudīt to kaut ko vidusslānī un līdz uzdevumam, kas prasa šo kaut ko nemaz nenonāk visās vietās, kur prasās šis kaut kas.

 

es te ņemos ar kohanu: http://kohanaframework.org/3.2/guide/orm/validation#automatic-validation

 

Bet tieši šāda izmantošana man nepatīk

Oh. My. God. 

[Kavacky]

Par to tavu kodu - apsvēri domu izmantot divas getAuth() metodes - getAuthUser() un validateGetAuth() kur getAuthUser atgriež kontu vai null (null - nav konta), kur nepieciešams un validateGetAuth() pārbauda lietotāju un ja lietotāja nav, saglabā esošo soli un nosūta lietotāju autorizēties?

Nu vai tu neesi daunis? Tā vietā, lai uzrakstītu vienu metodi ar exceptionu, ko apstrādā un nosūta ielogoties, tu rakstīsi divas metodes, lai varētu taisīt ķipa

if (Auth::validateGetAuth())
{
    $user = Auth::getAuth();
}
else
{
    showLogin();
}

Vai arī tu varētu pārbaudīt to kaut ko vidusslānī un līdz uzdevumam, kas prasa šo kaut ko nemaz nenonāk visās vietās, kur prasās šis kaut kas.

Vai arī tu varētu izbeigt būt daunis, jo ņehuj kaut ko pārbaudīt pa vidu visās reizēs, kad tiek izsaukta metode, ja var pārbaudīt tikai vienreiz - pašā metodē?

 

Ar tādu centību un tieksmi vairāk darīt tev grāvji jārok, nevis jāprogrammē. Jo no minētajiem tikai grāvju rakšanā ir svarīgs izraktā grāvja garums; jo garāks, jo labāk.

Edited March 12, 2013 by Kavacky

[F3llony]

No kurienes tieši tu izrāvi šo murgu? Parādi man, kur es kaut ko šādu aprakstīju?

if (Auth::validateGetAuth())
{
    $user = Auth::getAuth();
}
else
{
    showLogin();
}

Ibio. 

 

Kontrolierī - 

$user = Auth::getAuthUser();

Auth::getAuthUser kontrolierī nekad netiks izpildīts ja nav lietotāja. Tas tiek pārbaudīts un handlēts pirms tam. Bonusā - Auth::getAuthUser ir izmantojams arī ārpus kontroliera bāzes ar ACL, lai kontrolēti nodetektētu lietotāju, jo metode kontrolējami fallbacko uz null, ja nav lietotāja. Atkal, varam izmantot gan tā, gan tā. Piemēram, pievienojot darbības logā - tu vai nu konkatenē logline ar string vai nu sapisies savos exceptionos. Kā būs ērtāk - predefinēt mainīgo, pēc tam ar try catch ielikt tur lietotāja vērtību ja lietotājs ir vai nav vai arī konkatēt ar ternāru ifu?
 
Kontroliera bāzes klases __construct vai action invokā - 

Auth::validateGetAuth()

kas pārbauda lietotāju un ACL, un aizsūta lietotāju ielogoties, ja lietotāja nav. Pēc tam - MyController extends AuthController. Viss. 

 

Konstrukcijā būtu tikai viens ifs - validateGetAuth metodē. Neviena ifa vai izņēmuma kontrolierī. Papildus visam šim, netiek lieki invokēts kontroliera actions jo precondition nav izpildīts. 

 

Pie tam, kamēr tu pārrakstīsi visus savus līkos kontrolierus lai pamainītu autentifikācijas rutīnas ar saviem izņēmumiem un ifiem, es to izdarīšu vienā vietā - kontroliera bāzes failā.

 

 

Vēlviens codez, kas nejēdz lasīt, to kas rakstīts, bet no pirksta izzīž kaut kādus pieņēmumus. 

Edited March 12, 2013 by F3llony