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

[codez]

Viena lieta, kas man īsti nav skaidra:

try{
  $account->decMoney(...);
} catch (NepietiekNauda $e) {
  $account->decItems(...);
}
 

Tas ir kaut kāds anti-patterns ar exceptioniem vadīt flowu.

 

$account->decMoney() samazina naudu, ja naudas nepietiek, nerīkst samazināt un ir jāizmaet eksepšans.

Šis ir ļoti vienkāršs piemērs, tāpēc var likties, ka pārbaudīt naudas daudzumu pirms ir pareizāk, nekā mēģināt veikt darbību, bet reālos piemēros, kur darbības tiek sauktas vairākos līmeņos (izsauc vienu funkciju, kura izsauc citas funkcijas), ar pārbaudēm būs daudz lieka koda. Bez tam, ja nu ir vairākas vietas, kur izsaukt doto funkciju. Katrā tiks rakstīta viena un tā pati pārbaude? A, ja nu pēkšņi jāizmaina, ka tomēr var atļaut lietotājam iepirkties un ieiet ar naudu mīnusos līdz -100? Visās vietās, kur izmantots decMoney mainīsi pārbaudes?

 

Ja šis rada izbrīnu, tad man ir divi jautājumi:

1)Kādos apstākļos/kādām vajadzībām tu pats izmanto eksepšanus?

2)Kā šo tavuprāt būtu labāk rakstīt? (Ņem vērā, ka arī zelts var nepietikt un arī šis stāvoklis ir jāapstrādā).

[codez]

Principā tagad tiek apsriests, kurš no gadījumiem ir pareizāks.

1) Pārbaudes par to, vai varēs veiksmīgi veikt darbību tiek veiktas iepriekš un tad tiek veikta darbība, bet, ja pārbaudes netiek izietas, tad tiek apstrādāti izņēmuma gadījumi. Kods tam izskatās šādi:

if (someCondition1_1() and
    someCondition1_2() and
    ...
    someCondition1_N()){
  if (someCondition2_1() and
      someCondition2_2() and
      ...
      someCondition2_N()){
    doSomething();
  } else {
    handleUncondition2();
  }
} else {
  handleUncondition1();
}

2)Tiek uzreiz veikta darbība, kura pati sevī iekšā pasaka, ka tomēr nevarēs tikt veikta noteiktu iemeslu dēļ un pēc tam tiek apstrādāts katrs no iespējamajiem iemesliem:

try{
  doSomething();
} catch (Uncondition1Exception $e){
  handleUncondition1();
} catch (Uncondition2Exception $e){ 
  handleUncondition2();
}

Principā tā ir filozofija, ko šeit daži jau minēja - "It's easier to ask forgiveness than it is to get permission." Un šī frāze nāk no cilvēka, kas piedalījās pirmā kompilātora radīšanā. Pirmajā gadījumā mēs mēģinātu noskaidrot, vai mums ir atļauts veikt darību un tad veicam. Otrajā mēs viņu veicam un tad mēģinām savākt nekārtību, ja kaut kas nogāja ne tā.

Man ir jautājums, vai tiešām kāds uzskata, ka 1. variants ir vienkāršāks, vieglāk uzturams un vieglāk saprotams (pieņemot, ka ir izpratne par eksepšanu darbības mehānismiem), nekā 2. variants?

 

P.S. Es šeit nemaz nerunašu par gadījumiem, kad veicot 1. variantā pārbaudi kādam nosacījumam, viņš jau var būt mainījies, līdz mēs esam nonākuši līdz darbības izpildei.

Edited March 10, 2013 by codez

[marrtins]

Mainījies stāvoklis? T.i., kaut kur aizmirsās lock vai tiek darīts ārpus transakcijas? Tas jau iet offtopikā.

Nav obligāti pārbaudīt vai drīkst (par sliktu jau nenāk, protams). Taču var pārbaudīt f-ijas rezultātu.

Ja PHP varētu tāpat kā JS nocatchot sintakses kļūdas vai nedefinētas f-ijas, tad jau varētu sākt par šo sākt domāt.

Tāpat to try catch  var izmantot, ja viss izsauktas kods vispār met tos exceptionus un maksimāli daudz exceptioni ir sadefinēti (praksē labi ja puse no iespējamām kļūdām vispār ir nodefinētas kā exception). Tas ir faktiski tas pats kad f-ija atgrieztu error flagus:

 

define('E_PARMAZNAUDAS', 1);
define('E_NAVAUTORIZĒJIES', 2);
define('E_BANNED', 4);
define('E_FACECONTROL, 8);
utt.

 

 

Pēc tam

 

$e = doSomething();
if($e ~ E_PARMAZNAUDAS){
    rokamzeltu();
}
if($e ~ E_NAVAUTORIZĒJIES){
    sorryvecais();
}
...

 

[nemec]

$account->decMoney() samazina naudu, ja naudas nepietiek, nerīkst samazināt un ir jāizmaet eksepšans.

Šis ir ļoti vienkāršs piemērs, tāpēc var likties, ka pārbaudīt naudas daudzumu pirms ir pareizāk, nekā mēģināt veikt darbību, bet reālos piemēros, kur darbības tiek sauktas vairākos līmeņos (izsauc vienu funkciju, kura izsauc citas funkcijas), ar pārbaudēm būs daudz lieka koda. Bez tam, ja nu ir vairākas vietas, kur izsaukt doto funkciju. Katrā tiks rakstīta viena un tā pati pārbaude? A, ja nu pēkšņi jāizmaina, ka tomēr var atļaut lietotājam iepirkties un ieiet ar naudu mīnusos līdz -100? Visās vietās, kur izmantots decMoney mainīsi pārbaudes?

 

Ja šis rada izbrīnu, tad man ir divi jautājumi:

1)Kādos apstākļos/kādām vajadzībām tu pats izmanto eksepšanus?

2)Kā šo tavuprāt būtu labāk rakstīt? (Ņem vērā, ka arī zelts var nepietikt un arī šis stāvoklis ir jāapstrādā).

 

Nav viena pārbaude IF gadījumos jāraksta vairākās vietās.

try{
  $account->decMoney(...);
} catch (NepietiekNauda $e) {
  $account->decItems(...);
}

IFos tam būtu jāizskatās šādi

if($account->decMoney(...) === false){
  $account->decItems(...);
}

Un savukārt tajā decMoney tiek pārbaudīts vai pietiek naudas, ja nepietiek, tad atgriežam false piemēram (vai nu false, ja viss kārtībā un erroru, ja kaut kas nav kārtībā). Ja vēlāk robeža ir -100, tad tajā decMoney arī labojam. Tas ir tāpēc, ka šī pārbaude attiecas uz decMoney metodi.

 

try catch priekšrocība ir, ja aizmirsi apstrādāt tādu variantu kā nepietiek naudas, tad visa programma saplīsīs.

Edited March 10, 2013 by nemec

[codez]

Mainījies stāvoklis? T.i., kaut kur aizmirsās lock vai tiek darīts ārpus transakcijas? Tas jau iet offtopikā.

Ne visur ir transakcijas (faili, memcached, utml.) tāpēc sanāks lietot lockošanu.

Ja ikdienas rutīnā tiek ievietota vēl lokošana, tad tas viss paliek vēl sarežģītāk:

 

lockCondition1_1();
lockCondition1_2();
...
lockCondition1_N();
if (someCondition1_1() and
    someCondition1_2() and
    ...
    someCondition1_N()){
  lockCondition2_1();
  lockCondition2_2();
  ...
  lockCondition2_N();
  if (someCondition2_1() and
      someCondition2_2() and
      ...
      someCondition2_N()){
    doSomething();
  } else {
    handleUncondition2();
  }
  unlockCondition2_1();
  unlockCondition2_2();
  ...
  unlockCondition2_N();
} else {
  handleUncondition1();
}
unlockCondition1();
unlockCondition2();
...
unlockConditionN();

Nav obligāti pārbaudīt vai drīkst (par sliktu jau nenāk, protams). Taču var pārbaudīt f-ijas rezultātu.

 

Okay, tas ir trešai variants, bet šim variantam ir pilns ar nepilnībām, ja kļūdas stāvoklis ir jāpadod nestēti un katra nākošā funkcija, kura izsauc citas funkcijas ir spiesta visus iespējamos stāvokļus padod tālāk:

 

function doSomething1(){
  if (someContition1()){
    do();
    return 0;
  } else {
    return someError1;
  }
}

function doSomething2(){
  if (someContition2()){
    $err=doSomething1();
    ir ($err) return $err;
    do2();
    return 0;
  } else {
    return someError2;
  }
}
...
function doSomethingN(){...}

function f3(){
  if ($err=doSomething1()) return $err;
  if ($err=doSomething2()) return $err;
  ...
  if ($err=doSomethingN()) return $err;
  return 0;
}

$err=f3();
if (err==someError1) handleUncondition1();
if (err==someError2) handleUncondition2();
...
if (err==someErrorN) handleUnconditionN();
 

Bet tas strādā kaut cik, tikai gadījumā, ja jāpadod 1 vienīgs kļūdas stāvoklis līdz augšai un neviena no izsaucamajām funkcijām neatgriež vērtību. A ko darīt, ja funkcija reāli atgriež vērtību? Var jau protams vienu no vērtības stāvokļiem izmantot kā kļūdas stāvokli, bet, ko darīt, ja kļūda nav bool, bet ir jāpadod reāls kļūdas stāvoklis, vai arī atgriežamā vērtība aizņem visu atgriežamās vērtības diapazonu? Ko darīt, ja iespējamie kļūdas stāvokļi ir daudz un nav gluži no vienas kategorijas? - jāveido vesela kļūdu uzskaites arhitektūra, kur katrai kļūdai ir sava vērtība, kas pie tam nepārklājas ar nevienu funkcijas atgriežamo vērtību.

 

Ja PHP varētu tāpat kā JS nocatchot sintakses kļūdas vai nedefinētas f-ijas, tad jau varētu sākt par šo sākt domāt.

Visas notices un errorus ar handleri var pārķert un paŗtaisīt par exceptioniem - tā ir normāla prakse.

Tāpat to try catch  var izmantot, ja viss izsauktas kods vispār met tos exceptionus un maksimāli daudz exceptioni ir sadefinēti (praksē labi ja puse no iespējamām kļūdām vispār ir nodefinētas kā exception). Tas ir faktiski tas pats kad f-ija atgrieztu error flagus:

Tas ir tas pats, kas ar ifiem nepārbaudīt visus iespējamos kļūdu stāvokļus pēc izpildes, vai nosacījumus pirms izpildes. Ja ar ifiem netiks pārbaudīti visi stāvokļi, tāpat kādu kļūdu var palaist garām. Tas pats ir ar try catch - ja kāda kļūda pēkšņi nemetīs ekceptionu, tad viņu var palaist garām.

[marrtins]

Par lockošanu un transakcijām jau teicu - offtopiks. No sarežģītības neizbēgt, ja reiz tas nepieciešams.
Ja f-ijai ir uzdevums atgriezt citas f-ijas rezultātu - tas ir jāparedz un attiecīgi jākodē. Savādāk izklausās, ka tas try catch Tavā gadījumā ir vnk globāls error handleris, kurā kļūdas neapstrādāsi pilnīgi visiem gadījumiem - to daudz ērtāk ir darīt uz vietas pēc konkrētās f-ijas izsaukšanas un pa rokas esot vajadzīgiem parametriem un tajā gadījumā jau vairs nav nekādas nozīmes - catch vai if. Excpetion jau pēc definīcijas ir izņēmumgadījums. Tāds, kas iepr nav definēts.

 
Ar PHP error handleri nepārķersi sintakses kļūdas vai nedefinētas f-ijas izsaukšanu.
Lūk piemēram reāls exception:
 

 

try {
    include("a.php");
} catch(Exception $e) {
    print "b";
}
 

Kur a.php satur drazu - nedefinētas f-ijas vai sintakses kļūdas. Ja ar PHP to varētu šādi pārķert būtu labi.

[codez]

 

IFos tam būtu jāizskatās šādi

if($account->decMoney(...) === false){
  $account->decItems(...);
}

 

Un savukārt tajā decMoney tiek pārbaudīts vai pietiek naudas, ja nepietiek, tad atgriežam false piemēram (vai nu false, ja viss kārtībā un erroru, ja kaut kas nav kārtībā). Ja vēlāk robeža ir -100, tad tajā decMoney arī labojam. Tas ir tāpēc, ka šī pārbaude attiecas uz decMoney metodi.

Tas ir tas pats, ko marttins tikko teica.

1.Redz, piemirsās nosacījums, ja nu itemi ar nepietiek.

2.Šāds kods ir viennozīmīgi neuzskatāms un var būt maldinošs, jo pirmā doma ir, kaut ko pārbaudam, tad taisām decItems(), kaut kan patiesībā if nosacījumā ir ielikta reāla darbība.

3.Bet, ko darīsi, ja izpildāmā funkcija pati kaut ko atgriež vai, piemēram, izpildāmajai funkcijai var būt vairāki iespējami kļūdu stāvokļi?

Bet, ja iespējamie kļūdu stāvokļi ir daudz un dažādi?

Vei, piemēram, gadījums, kad tu pērc par naudu no cita accounta, bet accountam ir ierobežots saņemamās naudas daudzums un vienai naudas transakcijai ir limits naudas limits - kļūdas var būt vesela trīs veida:tev nepietiek naudas, otram jau ir limits, transakcijas apjoma limits. Tagad tev ir jāpārbauda un jāapstrādā veseli trīs gadījumi. Bet tas vēljoprojām ir vienkārš variants. Realā aplikācijā var būt funkcijas izsaukums, kurā ir iespējamas vairāk kā pāris desmiti dažādas kļūdas, kur dažām vajag parādīt kļūdu ziņojumu, pie dāžam vajag izpildīt kādu citu darbību, utt.

 

 

try catch priekšrocība ir, ja aizmirsi apstrādāt tādu variantu kā nepietiek naudas, tad visa programma saplīsīs.

Man personīgi praksē ļoti daudz reizes ir bijus tāda "WOW" situācija, izmantojot try catch, ka pēķšņi strādā visi iespējamie kļūdu veidi, kaut rakstot doto funkcionalitāti, par to pat netika piedomāts, jo reāli pati pārbaude ir tieši tajā vietā, kur rakstīta pati darbība, bet vietās, kur tu izsauc darbību, tev vairs nav pat jāuztraucās par pārbaudēm, jo viss notiek automātiski. Mazāk kļūdu, ātrāk izstrāde, vienkāršaka arhitektūra, kas ļauj veidot lielas un viegli uzturamas aplikācijas.

Kā jau iepriekš minēju, gadījumā ar itema pirkšanu, itema pirkšana funkcionalitāte būtu:

 

 

$account->decMoney($price*$ammount);
$account->addItem($item,$amount); 

Un viss - visu kļūdu testēšana, kļūdas paziņojumu apstrāde, aplikācijas plūsmas kontrole jau notiek pareizi un pilnīgi, pat gribēdams, nevar aizmirst kaut ko nepārbaudīt, vai palaist aplikāciju pa ceļu, kur tā nedrīkstētu iet.

[marrtins]

Nu bet vēlreiz - šajā decMoneu un uzreiz addItem iztrūks alternatīvie izpildes ceļi (ņemt naudu no cita maka?). Tāpēc jau ir f-iju un ir definēts, ko tā atgriež. Ja atgriež ne to, kas dokumentācijā - exception, izņēmumstāvoklis. Ja reiz atgriež naudas nav, vai neņem pretī, vai nav autorizēts vai vēl 100 no definētiem errroriem, tad uzreiz attiecīgi var rīkoties nevis vnk padot uz augšu erroru globālam error hanlderim.

 

Kā Tu padosi divus error stāvokļus? Metīsi divus exception? :)

 

Vnk nevajag jaukt kļūdu ar izņēmumstāvokli.

[codez]

Par lockošanu un transakcijām jau teicu - offtopiks. No sarežģītības neizbēgt, ja reiz tas nepieciešams.

Nav gan offtopiks. Jo gadījumā bez eksepšaniem, tev lokošana paliek par ikdienas rutīnas darbu un ir kaut kādā veidā jāizsauc katru reizi, pie darbības izsaukšanas, kamēr eksepšanu gadījumā lokošana atrodas tajā paša vietā, kur pati darbība.

Ja f-ijai ir uzdevums atgriezt citas f-ijas rezultātu - tas ir jāparedz un attiecīgi jākodē.

Tieši tā, bet kā tad padosi kļūdas stāvokli šij funkcijai, ja return jau tiek izmantots vērtības atgriešanai?

Atbilde - nekā. Paliek 2 gadījumi, vai nu taisīt if-us pirms funkcijas izsaukšanas, vai eksepšani.

Savādāk izklausās, ka tas try catch Tavā gadījumā ir vnk globāls error handleris, kurā kļūdas neapstrādāsi pilnīgi visiem gadījumiem

Nevis globāls, bet tāds, kas spēj pārnest kļūdas stāvokli un aplikācijas izpildes plūsmus uzreiz caur daudzām hirerhiali izsauktām darbībām. Tas ir rīks, kurš padara aplikācijas izstrādi vienkāršāku. Protams, ja tas ir kļūdas stāvoklis, kurš rodas pašā zemākajā aplikācijas slānī, piemēram, konekcijas ar db nav iespējama, un neviens visā izsaukšana ķēdē nevēlas šādu izņēmumu apstrādāt, tad to apstrādā Front Kontroleris, kurš padod tālāku palikācijas izpildi kļūdu paziņojuma kontrolerim.

Tu taču šādā gadījumā netaisi, ka db klasē tiek padota programmas izpilde kļūdas paziņošanas kontrolerim?

- to daudz ērtāk ir darīt uz vietas pēc konkrētās f-ijas izsaukšanas un pa rokas esot vajadzīgiem parametriem un tajā gadījumā jau vairs nav nekādas nozīmes - catch vai if.

es jau iepriekš parādīju piemērus, kas notiek visu darot uz vietas pie konkrētās funkcijas izsaukšanas. Un gadījumā ar eksepšaniem. Gadījumā ar eksepšaniem aplikācija ir daudz īsāka, saprotamākā, vieglāk uzturama, tāpēc ir nozēme, catch vai if.

Excpetion jau pēc definīcijas ir izņēmumgadījums. Tāds, kas iepr nav definēts.

Eksepšans ir izņēmums, bet nevis iepriekš nedefinēts, bet iepriekš skaidri definēts - tieši šī iemesla dēļ ir iespējami dažādu klašu eksepšanu un nestēti eksepšani.

 

Ar PHP error handleri nepārķersi sintakses kļūdas vai nedefinētas f-ijas izsaukšanu.

Lūk piemēram reāls exception: 

try {
    include("a.php");
} catch(Exception $e) {
    print "b";
}
 

Kur a.php satur drazu - nedefinētas f-ijas vai sintakses kļūdas. Ja ar PHP to varētu šādi pārķert būtu labi.

1. Manā FW principā viss notiek caur OOP, kur nedefinētas klases apstrādā autoload handleris.

2. Vienīgā vieta manā freimworkā, kur ir include, ir autoload handlerī.

3. Ja tomēr tik ļoti nepieciešams arī apstrādāt sintakses kļūdas, kuras parādās IDĒ tāpat, tad:

function myinclude($s){
  $res=eval(file_get_contents($s));
  if ($res===false) throw new SyntaxErrorException();
  return $res;
}
 

[codez]

Nu bet vēlreiz - šajā decMoneu un uzreiz addItem iztrūks alternatīvie izpildes ceļi (ņemt naudu no cita maka?). Tāpēc jau ir f-iju un ir definēts, ko tā atgriež. Ja atgriež ne to, kas dokumentācijā - exception, izņēmumstāvoklis. Ja reiz atgriež naudas nav, vai neņem pretī, vai nav autorizēts vai vēl 100 no definētiem errroriem, tad uzreiz attiecīgi var rīkoties nevis vnk padot uz augšu erroru globālam error hanlderim.

Vēlreiz 2 varianti ar pilnu piemēru: Tātad situācija - accounts pērk itemu par naudu. Ir dots itema cena - $price, skaits - $amount, un id - $itemid. Var nepietikt nauda, var būt pilns inventorijs, var būt, ka lietotājs nav ielogojies. Taču vēl, ja nauda nepietiek, tiek mēģināts pirkt par zeltu, kur prece zeltā maksās tik - $priceinggold.

1.Ar atgriešanu:

 

$account = new Account();
if (Auth::isSignedIn()){
  if (!$account->loadById(Auth::signedInId)) exitWithError('Account nof found!');
  $ok=true;
  if (!$account->decMoney($price*$amount)){//nauda nepeitiek, mēģināsim pirkt par zeltu
    if (!account->decItems(GOLDID, $ammount*$priceingold)){ //oij, zelts arī nepeitiek.
      $ok=false;
    }
  }
  if ($ok){
    if ($account->addItem($itemid, $amount)){
      db::commit();
    } else { //ups nav vietas
      exitWithError('Not enough space');
    }
  } else {
    exitwithError('Not enough money and gold');
  }
} else {
  exitWithError('Ups, not signed in');
} 

2. ar ekspešaniem, kur katru eksepšanu pārķer FW tajā vietā, kur attiecīgi jāmaina aplikācijas izpildes kontrolers plūsma. 

 

 

$account = Account::getAuth();
try{ 
  $account->decMoney($price*$amount); 
} catch(NotEnoughMoney $e){
  $account->decItems(GOLDID, $ammount*$priceingold);
}
$account->addItem($itemid, $amount);
db::commit(); 

Ja es kaut ko ne tā uzrakstīju 1. variantā, droši vari palabot, bet es nespēju iedomāties apstākļus, kuros 1. variants varētu izrādīties vienkāršāks. Pie tam es neesmu 100% pārliecināts, vai 1. variants vispār ir pareizs, kamēr par 2. nav nekādu šaubu.

 

Kā Tu padosi divus error stāvokļus? Metīsi divus exception? :)

Nē, nested exceptions:

http://phptrycatch.blogspot.com/2012/07/throw-your-own-nested-exceptions.html

[marrtins]

Tu esi nekorekti saīsinājis variantu ar IF uz catch. Pirmajā gad Tev jau ir erromsg iestrādāti, turpretim otrajā tie ja arī ir istrādāti, tad kaut kur citur (visticamāk). Tāpat arī ielogošanās pārbaude, acounta esamības pārbaude otrajā gadījumā ir kaut kur citur (iespējams).

 

$account = new Account();
$e = $account->buyWithDollars($price*$amount);
if($e ~ E_NOTENOUGHMONEY){
    $e = $account->buyWithGold($price*$amount);
    if($e ~ E_NOTENOUGHMONEY){
        return false;
    }
}
$account->addItem($itemid, $amount);
return true;

 

Ja nepieciešams atgriezt kaut ko vairāk, tad to vispirms vienojamies, ko f-ija atgriež un pieliekam, piemēram,

 

return array(
    'error'=>false,
    'amount'=>$amount,
    'price'$price,
    );

 

Ā un tie nested exceptions izskatās pēc totālām drausmām :)

Edited March 10, 2013 by marrtins

[codez]

 

Tu esi nekorekti saīsinājis variantu ar IF uz catch. Pirmajā gad Tev jau ir erromsg iestrādāti, turpretim otrajā tie ja arī ir istrādāti, tad kaut kur citur (visticamāk). Tāpat arī ielogošanās pārbaude, acounta esamības pārbaude otrajā gadījumā ir kaut kur citur (iespējams).

 

$account = new Account();
$e = $account->buyWithDollars($price*$amount);
if($e ~ E_NOTENOUGHMONEY){
    $e = $account->buyWithGold($price*$amount);
    if($e ~ E_NOTENOUGHMONEY){
        return false;
    }
}
$account->addItem($itemid, $amount);
return true;

 

Ja nepieciešams atgriezt kaut ko vairāk, tad to vispirms vienojamies, ko f-ija atgriež un pieliekam, piemēram,

 

return array(
    'error'=>false,
    'amount'=>$amount,
    'price'$price,
    );

 

 

Es reāli ceru, ka tu apzinies, ka tavs variants ir daudz komplicētāks.

Pēc kārtas:

1. Tavā variantā:

- nav konta ielāde,

- nav pārbaude, vai lietotājs ir autorizējies,

- nav šo abu gadījumu apstrāde un kļūdas ziņojuma paziņošanas.

- nav pārbaude, vai pietiek vietas un šī kļūdu ziņojuma paziņošana.

- ir pārbaude uz to, vai pietiek nauda, vai zelts, bet nepietikšanas gadījumā nav tālāka kļūdas stāvokļa un kļūdas ziņojuma nodošana un apstrāde.

2. Ja tu tomēr uzskati, ka ir negodīgi nogriesti error paziņojumi, tad parādi, kurā vietā tu iestrādāsi šos error paziņojumus, kurā vietā tu tos attēlosi un kā tu padosi kļūdas/izņēmuma/speciālgadījuma stāvokli no vietas, kur kļūda rodas uz vietu, kur tā jāapstrādā un tālāk uz vieut,kur tā jāattēlo? Nespēju iztēloties, lai tev sanāktu kaut tuvu tik elegants un īss kods kā man.

 

3. Kas attiecas un return array(..., kurš sevīs satur gan visus iespējamos kļūdas stāvokļus, gan funkcijas atgriežamos datus, tad tā vispār ir reāla pronogrāfija un pad nedaudz prātā iedomājoties, kā izskatīties pēdējais apskatītais piemērs, šermuļi pārskrien.

[marrtins]

Kāpēc tai f-ijai būtu jānodarbojas ar autorizācijas pārbaudi, konta ielādi? Tam ir citas f-jas. Bet, vai Tavā kodā tas viss bija? :O Kļūdu (ne)paziņošana lai paliek izsaucēja pārziņā - lai kas tas arī būtu CLI vai HTTP vai vienalga kurā vidē un kādā formātā.

Laikam pārprati par return array(). Kādā sakarā tam būtu jāsatur *visi* iespējamie stāvokļi vai dati?

[nemec]

Codez, ja tev ir tajā bywithDollars: if not enough raise error, tad ifiem ir if not enough return error.

[codez]

Kāpēc tai f-ijai būtu jānodarbojas ar autorizācijas pārbaudi, konta ielādi?

Tāpēc, ka attiecīgo darbību var veikt tikai autorizēts lietotājs.

Tam ir citas f-jas. Bet, vai Tavā kodā tas viss bija? :O

Jā, bija, bija gan pārbaude, kas atrodas Account::auth funkcijā, gan arī kļūdas izsaukšana un kļūdas stāvokļa pārnešana ar eksepšanu uz FC.

Ja tu saki, ka tavā variantā arī tas viss, tad parādi, kā tu nosaki, ka šo funkciju drīkst izpildīt tikai autorizēts lietotājs, kā tiek ģenerēta kļūda un kā tā tiek padota vietai, kur tā tiek attēlota?

Kļūdu (ne)paziņošana lai paliek izsaucēja pārziņā - lai kas tas arī būtu CLI vai HTTP vai vienalga kurā vidē un kādā formātā.

Jā, lai paliek, bet kā tas izsaucējs zinās, kāda tieši kļūda ir un kas ir jāpaziņo? Un kā tu savā gadījumā šo kļūdas stāvokli pārnesīsi no augstāk izsauktām funkcijām uz zemākām.

Laikam pārprati par return array(). Kādā sakarā tam būtu jāsatur *visi* iespējamie stāvokļi vai dati?

Visi iespējami domāts, ka kļūdas var būt dažādas - vienai ir paziņojums, citai kaut kas jāielogo, citai vēl kaut kas. Visa šī informācija tev būtu jāpārnes caur šo array(). Kamēr eksepšanu gadījumā katrs kļūdas veids ir klase, kura smugi glabā viskompleksākos datus, ja tas nepieciešams un par kuras pārnešanu nav jāuztraucas, jo try catch mehānisms to nodrošina.