Jump to content
php.lv forumi

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


Grey_Wolf

Recommended Posts

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

Jā, lai tā ir, bet tas nekādi nepadara if-u variantu vienkāršāku.

Pie tam, ko errors atgriezīs?

kļūdas kodu? kļūdas ziņojuma tekstu?

kas viņu pados tālāk tai vietai, kur šī kļūda ir jāattēlo?

Uzraksti savu variantu kā tas izskatīsies kopumā un redzēsi, ka tev sanāks daudz sarežģītāk kā man.

Link to comment
Share on other sites

  • Replies 149
  • Created
  • Last Reply

Top Posters In This Topic

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

Nu bļins jāsāk lamāties. Kāda starpība kur un kādā veidā tas tiek noteikts? Galvenais, lai naudas noņemšanas f-ija neļauj veikt darbību. Paziņojot ar return atbilstošu error kodu. Kas to attēlos un kā - arī kāda šķirba? Kaut vai tavs kļūdu attēlotājs, kaut vai custom error handleris, kaut vai die(). F-ijas izsaucējs zin interfeisu un f-ijas return kodus. Kur problēma? Ja dikti nepieciešams pārnest pa call stack, tad var ar array, object, string, kodiem, citām f-ijām - izvēlies. Tas try catch nodrošina, bet var arī bez tā, jo nekāds mega ieguvums tas tāpat nav.

Link to comment
Share on other sites

Nu bļins jāsāk lamāties. Kāda starpība kur un kādā veidā tas tiek noteikts? Galvenais, lai naudas noņemšanas f-ija neļauj veikt darbību. Paziņojot ar return atbilstošu error kodu. Kas to attēlos un kā - arī kāda šķirba? Kaut vai tavs kļūdu attēlotājs, kaut vai custom error handleris, kaut vai die().

Kāds vēl "bļin"?

Tad uzraksti kā tas mehānisms strādās un tu redzēsi, ka ar eksepšaniem ir daudz, daudz ērtāk.

Kā tavā gadījumā kļūdas attēlotājs vai custom error handleris attēlos kļūdas/speciālgadījuma ziņojumus un kā viņš to saņems?

F-ijas izsaucējs zin interfeisu un f-ijas return kodus. Kur problēma? Ja dikti nepieciešams pārnest pa call stack, tad var ar array, object, string, kodiem, citām f-ijām - izvēlies.

Un zin arī visus return kodus funkcijām, ko izsauc funkcijas, kuras izsauc funkcija, kuru izsauc sākumā?

Bez tam eksepšanu gadījumā konkrētajam funkcijas izsaucējam nav jāzin kodi, jo, ja viņš nevālās konkrētos izņēmuma gadījumus apstrādāt, tie tiks automātiski pārnesti un šī izsaucēja izsaucēju, kamēr if-u gadījumā izsaucējam jānodrošina šī kļūdas stāvokļa pārnešana - katru reizi.

Tas try catch nodrošina, bet var arī bez tā, jo nekāds mega ieguvums tas tāpat nav.

Ir gan. Un ieguvums ir milzīgs un to jau es nodomestrēju uz neskaitāmiem piemēriem.

Neviens programmas izpildes plūsma kontroles mehānisms nenodrošina tiešā veidā to, ko nodrošina eksepšani un, nodrošinot to savādāk, rodas daudz lieka koda.

Link to comment
Share on other sites

Codez,

1. Neautorizēts lietotājs līdz autentikāciju prasošam kontrolierim dabiski nevar nonākt. Tas jānokontrolē kontroliera bāzes klasei vai sliktākajā gadījumā FC.

2. Ja "inventorijā" nav vietas - NAKUJ tu vispār ļauj sākt pirkumu?! Nav vietas - nav iespējams pirkums - par to apmeklētājam paziņo pirms vispār tu esi sācis kaut ko rēķināt vai reģistrēt pirkuma itemus. Tava mākslīgi radītā problēma ir kļūda loģikā. Period. 

3. Tas pat ar maksājumiem - tu neļauj lietotajam pirkt kaut ko, kam viņam nepietiek valūtas, jo acīmredzot tranzakcija notiek ar sistēmas kontrolējamu naudu. Atkal loģikas kļūda un atkal mākslīgi radīta. Ja apmaksu kontrolē ārēja sistēma, tu par konta stāvokli uzzināsi no callback, no šīs sistēmas, kur attiecīgi pēc callback arī uzzināsi vai ir nauda, vai ir apmaksāts un kas galu galā notiek. 

4. Validācija ir pie kājas. Validāciju atkarībā no sistēmas arhitektūras veic vai nu formas validatora klase, vai modelis, vai kontrolieris. Neviens no variantiem nav nepareizs. 

 

Vēlreiz atkārtoju, FC uzdevums ir nodot routes noteiktam kontrolierim kontroli pār uzdevumu. Kontrolieris savukārt var paplašināt dajebko lai panāktu sev nepieciešamo rutīnu setu un to automatisku/manuālu izpildi. 

 

Un pēdējo reizi atkārtoju lielim burtiem, lai galēji būtu skaidrs vienreiz un uz visiem laikiem - Exception jeb izņēmums nozīmē anomālu vai normālā programmas plūsmā neiespējamu notikumu, kā piemēram, zudis DB savienojums, atvienots sokets, pazuduši dati, crash, vēl kaut kas. Anomāls nozīmē to, ka normālā programmas plūsmā ir tieši 0 thrown un 0 catched izņēmumi. Lietotāja statuss, konta atlikums un visi pārējie dati ir tranzakciju dati un neatbilst izņēmumu lietošanas paradigmai un eksistences mērķim kā tādam. Datu validācijai un normālas programmas plūsmas apstrādei izņēmumus nelieto.

 

No sākuma izskatījās, ka tikai tava prakse ir nekam nederīga. Nu izskatās, ka arī teorijā esi tālu no tā, ko es sauktu par sajēgu. Also, "ērtāk" ir ļoti relatīvs jēdziens. Tavu nolāpīto izņēmumu bāzēto sūdu debugot būtu tik pat viegli, kā norīt ballistisko raķeti, jo ir tik ērti un jauki izsekot programmas plūsmai. Slinkums tas ir, darīt lietas pareizi. Un viss. 

 

 

P.S ko jūs te ņematies ar error kodiem? Jūs toč web aplikācijas programmējat TĀDĀ veidā - bezmaz kā unix? Lineārā kodā?...

Edited by F3llony
Link to comment
Share on other sites

Codez,

1. Neautorizēts lietotājs līdz autentikāciju prasošam kontrolierim dabiski nevar nonākt. Tas jānokontrolē kontroliera bāzes klasei vai sliktākajā gadījumā FC.

Bullšit.

Es kontrolerus iedalu pēc aplikācijas strukurālā iedalījuma, nevis pēc tā vai to var lietot autentificēts lietotājs, vai nē.

Piemēram, postu kontrolerī man var būt 2 actioni - posts un newpost. 1. atgriež kaut kādu postu sarakstu un to var veiksmīgi izsaukt neautorizēts lietotājs, kamēr 2. pievieno postu un to var izsaukt tikai autorizēts.

2. Ja "inventorijā" nav vietas - NAKUJ tu vispār ļauj sākt pirkumu?! Nav vietas - nav iespējams pirkums - par to apmeklētājam paziņo pirms vispār tu esi sācis kaut ko rēķināt vai reģistrēt pirkuma itemus. Tava mākslīgi radītā problēma ir kļūda loģikā. Period.

Pat, ja frontends zinātu, ka vietas pietrūks, backendā ir tik un tā jāveic pārbaude. Bez tam šis ir piemērs un tik pat labi var būt gadījumā, kad frontends nezin, vai vietas pietiek, bet lietotājs veic darbību. Bet tik un tā, abos gadījumos ir jāveic šī pārbaude, jo kāds hakeris var apiet frontenda pārbaudi.

3. Tas pat ar maksājumiem - tu neļauj lietotajam pirkt kaut ko, kam viņam nepietiek valūtas, jo acīmredzot tranzakcija notiek ar sistēmas kontrolējamu naudu. Atkal loģikas kļūda un atkal mākslīgi radīta. Ja apmaksu kontrolē ārēja sistēma, tu par konta stāvokli uzzināsi no callback, no šīs sistēmas, kur attiecīgi pēc callback arī uzzināsi vai ir nauda, vai ir apmaksāts un kas galu galā notiek.

Ko tu murgo, kāda ārēja sistēma, kādi callback. Beidz taču pīpēt to kapronu.

Ir account, kuram ir money lauks un frontends nezin vai pietiek, vai nē un backendā ir jāpārbauda tik un tā.

4. Validācija ir pie kājas. Validāciju atkarībā no sistēmas arhitektūras veic vai nu formas validatora klase, vai modelis, vai kontrolieris. Neviens no variantiem nav nepareizs.

Piekrītu, ka atkarībā, ko validējam, validācija var atrasties dažādās vietās, ko pirmīt jau arī rakstīju.

Vēlreiz atkārtoju, FC uzdevums ir nodot routes noteiktam kontrolierim kontroli pār uzdevumu. Kontrolieris savukārt var paplašināt dajebko lai panāktu sev nepieciešamo rutīnu setu un to automatisku/manuālu izpildi.

Tikai nesaki, ka tālāk, ja pēkšņi uzdevuma izpilde jānodod citam kontrolerim, to dara patvaļīgi izsaukta metode, kurā radies izņēmums? Kur tad FC atbildība un kompetence par to, kuram kontrolerim ir jānodod uzdevums?

Nē, to dara tas pats FC, kurš saņem ziņojumu. Kā saņemt, tas jau ir arhitektūras jautājums. Es piedāvāju FC šo izņēmuma stāvokli nodot caur eksepšaniem, jo tā ir daudz ērtāk.

Un pēdējo reizi atkārtoju lielim burtiem, lai galēji būtu skaidrs vienreiz un uz visiem laikiem - Exception jeb izņēmums nozīmē anomālu vai normālā programmas plūsmā neiespējamu notikumu, kā piemēram, zudis DB savienojums, atvienots sokets, pazuduši dati, crash, vēl kaut kas. Anomāls nozīmē to, ka normālā programmas plūsmā ir tieši 0 thrown un 0 catched izņēmumi. Lietotāja statuss, konta atlikums un visi pārējie dati ir tranzakciju dati un neatbilst izņēmumu lietošanas paradigmai un eksistences mērķim kā tādam. Datu validācijai un normālas programmas plūsmas apstrādei izņēmumus nelieto.

Tev nav taisnība.

Tu reāli nemāki domāt out of box. Es ieņēmis kaut ko prātā un domā, ka tā ir aksioma. Pie tam esi aplami ieņēmis prātā.

Praksē eksepšans ir tāds pats rīks, kā if, while, for un citi izpildes plūsmas kontroles mehānismi, nav konkrētu aksiomu, ko kur drīkst izmantot un ko nedrīkst. Bez tam "normālā" (nauda pietiek, inventorijā vieta pietiek, lietotājs ir autorizējies) gadījumā arī eksepšana nebūs.

 

Lūk tev piemēri, kā domā vairums ekspertu citās valodās:

Kā kontrolēr nepareizas vērtības kontruktorā? (būtībā datu validācija)

http://stackoverflow.com/questions/1158410/how-to-handle-incorrect-values-in-a-constructor

Atbilde: "The typical solution is to throw an exception."

 

No sākuma izskatījās, ka tikai tava prakse ir nekam nederīga. Nu izskatās, ka arī teorijā esi tālu no tā, ko es sauktu par sajēgu. Also, "ērtāk" ir ļoti relatīvs jēdziens. Tavu nolāpīto izņēmumu bāzēto sūdu debugot būtu tik pat viegli, kā norīt ballistisko raķeti, jo ir tik ērti un jauki izsekot programmas plūsmai. Slinkums tas ir, darīt lietas pareizi. Un viss.

 

 Kopumā šo novelšu uz tavu nelielo vecumu un mazo pieredzi.

Edited by codez
Link to comment
Share on other sites

1. Bullshit? Tad posts un administratīva funkcija addpost būs vienā kontrolierī? What the fuck? QA tev par šito pateiks milzīgu paldies. Strukturālais iedalījums my ass, nu dien... Administratīva un ne administratīva funkcija nav strukturāla atšķirība, pilnīgi sader kopā bļ. Hurr durr.

2. Pisec, nu taču goda vārds, izlasi, ko rakstu es un izlasi ko raksti tu. Un beidz izzīst no pirksta pieņemumus, kurus neesmu izteicis. Frontenda validācija tu... Vāks.

3. Tu nekad neesi strādājis ar ārējām maksājumu sistēmām? Jebko ārēju? Man tev pastāstīt, kas ir servisa callback? Un kāpēc, lai frontends to nezinātu? Tu gribi teikt, ka frontends ir kaut kā mistiski izolēts no backenda? Jeb tu atkal nespēj izlasīt ko es rakstu un izdari kaut kādus no pirksta izzīstus pieņēmumus?

4. ....?

5. Kāpēc jānodod citam kontrolierim? Nomaini izvadi? Vai galēji, ja nu tik tiešām gribi visu sarežģīt - HMVC.

 

 

Un par to pēdējo, nu joptv-micīt, atradis stackowerflovā (ironiski) implementāciju, kur savādāk, kā bez exception nevar (konstruktori nespēj atgriezt vērtības. kāds jaunums...) un kur loģiski, un pamatoti būtu jāmet exception, jo tiek padoti neparedzēti dati (pre-validācija nav notikusi vai notikusi nekorekti). Tas ir jauki, taču tavam piemēram nav absolūti nekāda sakara ar tevis šeit apspriesto keisu, jo normālā gadījumā līdz Time klasei nekad nevajadzētu nonākt nekam citam, kā derīgam laikam - ja notiek tā, tad tā ir anomāli un atbilst izņēmumu pielietojumam. Tā pat, kā exception būtu jāmet, ja tā vietā lai transact padotu summu, tam padotu piemēram objektu. Tā ir anomālija, un būtībā tā nav pat tuvu validācijai. Es nezinu, kā šis keiss ir jāperversē lai tā būtu validācija, nu tiešām nezinu. Laikam tikai ignorējot validāciju kā tādu un datus pa tiešo barojot Time. Bet to neviens sevis cienīgs programmētājs nedarītu, ja labi zināms, ka Time prasa tieši tādas un tikai tādas vērtības. Ironiski, bet humors ir, ka bļaujot, ka man nav taisnība un noveļot to uz manu nelielo vecumu un mazo pieredzi tu postē piemērus, kuri norāda uz manu taisnību. Par to, ka tev gar manu pieredzi vispār nav nekādas sajēgas, nemaz nerunāsim. 

 

 

The logic behind that is the following: the constructor is a method that transforms a chunk of memory into a valid object. Either it succeeds (finishes normally) and you have a valid object or you need some non-ignorable indicator of a problem. Exceptions are the only way to make the problem non-ignorable in C++.

 

Praksē katram rīkam ir sava nozīme - out of the box domāšana ļauj šos rīkus kombinēt iepriekš neparedzētos veidos lai konstruktīvi risinātu problēmu. Out of the box nenozīmē tēlot idiotu un steitu padot ar izņemumiem.

 

Un tas, ka tu nespēj uztvert kontekstu manis sacītajam un viss tev jāiebaro kā 3klasniekam jau vien norāda uz to, ka tu vispār nejēdz, par ko šeit tik karsti diskutē un ar tavu pieredzi es godīgi sakot varu dibenu atslaucīt. 

Edited by F3llony
Link to comment
Share on other sites

F3llony, labi, beidz tukši muldēt, vienkārši uzraksti kā tu uzbūvētu manis pēdējo doto situāciju un salīdzināsim.

 

P.S. Iepriekšējā postā nepiekrītu nevienam tavam apgalvojamam. Visi tie ir vai nu pilnīgi vai daļēji apalami, vai velk uz sliktas prakses izmantošanu.

Edited by codez
Link to comment
Share on other sites

Kas tad nu, beidzās argumenti?...

 

Es labprāt to izdarīšu. 25LVL/h. ir mana rate. Un pacenties aprakstīt savu "situāciju" viena posta ietvaros...

 

P.S. Nepiekrīti, cik vien uziet. Tas vienalga nepadara to tavu smieklīgo perversiju par jēdzīgu risinājumu... Vismaz šīs "situācijas" ietvaros ne. 

 

P.P.S. Hei hei, sanāk sanāk, es arī varu izdomāt "out-of-the-box" risinājumus! 

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

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

goto.png

WINNER!!1111

Edited by F3llony
Link to comment
Share on other sites

Kas tad nu, beidzās argumenti?...

 

Parasti neielaižos garās diskusijās ar cilvēkiem, kas mani saukā par idiotu, kaut paši švaki orientējas dotajā tēmā.

Pie tam es savus argumentus esmu pietiekami labi izklāstījis ar reāliem piemēriem, kamēr tu nē.

Es labprāt to izdarīšu. 25LVL/h. ir mana rate. Un pacenties aprakstīt savu "situāciju" viena posta ietvaros...

Kur tik lēti?

Bet, ja nopietni, ja tev būtu kaut mazākā pārliecība, ka tavs variants ir labāks, tu sen jau to būtu jau uzrakstījis.

Link to comment
Share on other sites

P.P.S. Hei hei, sanāk sanāk, es arī varu izdomāt "out-of-the-box" risinājumus! 

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

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

 

 

Šis ir tavs piemērs, kā tu risinātu šo problēmu?
Link to comment
Share on other sites

Nu labi, pieņemsim, ka die vietā ir Response::blablabla :D

ja izpildīsies $item->price > $account->balance, būs bezgalīgais cikls.

 

P.S. Izskatās, ka tu esi ļoti tālu no programmēšanas, jo tu pat vienkāršus humoristiskus piemērus nespēj pareizi uzrakstīt.

Edited by codez
Link to comment
Share on other sites

:D nu te vairs nevar šito cilvēku nopietni ņemt, nu nevar... Vai nu trollē, vai nu tiešām ir pilnīgs idiots. Viņu pilnīgi nemulsina fakts, ka loģiski pirms goto endpointiem būtu jābūt kodam, kas izsauc kontrolieri. Līdz tam taču jādadomājas. Vai vajadzēja iebakstīt ar pirkstu acī. :D 

 

Lai komūna man piedod, es pametu šo topiku. :D Šodienai esmu pietiekami izsmējies, nododu stafeti tālāk. 

Edited by F3llony
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...