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

[codez]

Lai komūna man piedod, es pametu šo ...

Es ceru, ka tas nebija mājiens, ka taisīsi pašnāvību, jo pēkšņi sabruka tava visa paša izveidotā iedomu pasaule vai iestājās depresija no tā, ka tev nav taisnība un nevari uzrakstīt labāku realizāciju kā tā, kura ir pretrunā ar taviem principiem?

[nemec]

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.

Teiksim tā, neaizstāvu IFu variantu kā pareizo, bet kretinē, ka rādi tādus piemērus, kur jau ir loģiski pielaistas kļūdas plānošanā. Abi varianti spēj eksistēt, katrs izvēlas pēc vajadzībām. Ja python`ā dalīsi ar nulli, saņemsi ZeroDevisionError, darīsi to pašu PHP — saņemsi ierakstu error.log datnē kā warningu. Kādam patīk 1. variants, citam 2., ko tur daudz cepties.

 

Smieklīgi, ka tevi nesaprot PHP komūna, nāc uz python, tur tevi sapratīs :D

Edited March 10, 2013 by nemec

[daGrevis]

Nāc! Nāc!

 

Mums ir kaudze ar eksepšeniem. http://bpaste.net/show/fxCK9oFChdhe95c2Z9u4/

[Mr.Key]

+marrtins, F3llony

[codez]

Mr. Key, nekautrējies, piedāvā savu koda variantu.

Pagaidām no dažiem dzirdu, ka tā darīt nedrīkst, bet neviens ērtāku, īsāku, loģiskāku un saprotamāku variantu nevar piedāvāt.

[Mr.Key]

Īsāk nenozīmē saprotamāk, saprotamāk nenozīmē īsāk. Kā jau te tika minēts, Exceptions izmanto izņēmumsituācijām, nevis biznesa loģikas kontrolei. Ja biznesa loģika ir gara un sarežģīta, tad tas tā arī ir. Kā novērst koda dublēšanu un kur izvietot šo sarežģīto loģiku? Tas ir arhitektūras lēmums, jau minētā izvēle starp fat controllers/thin models vai thin controllers/fat models. Vai šo darbību veiksim kontrolierī, vai konta (account) modelī, vai pat veidosim atsevišķu modeli? Ja veidojas gari, nepārskatāmi IFi, tos var saīsināt, pārnesot uz metodēm ar pašdokumentējošiem nosaukumiem, kontrolierī vai modeļos un IFu saturu aizvietojot ar šo metožu izsaukumiem.

 

Nesaku, ka ar Exceptions nevar panākt līdzīgu rezultātu, bet... arī ar GOTO var daudz ko izdarīt. Es gan tā nedarītu. Esmu tā darījis, tas kods man pašam nepatīk un tika/tiek pārtaisīts. Exceptions neiesaka lietot tā, kā to apraksti Tu. Laika trūkuma dēļ nevaru iedot atsauces vai izveidot koda paraugu, taču, ja tas nav pavisam droši, vismaz es esmu pārliecināts, ka tā pat ir slikta prakse. Un arī koda vienkāršošana reizēm, bet ne vienmēr, nozīmē tieši to, ka kods tiek izveidots garāks un darbojas lēnāk, un to izveidot aizņem ilgāku laiku. Taču, vai Tu zini, ko nozīmē uzturēt ātri un pa savam izveidotu sistēmu un ieviest tajā izmaiņas?

Edited March 11, 2013 by Mr.Key

[daGrevis]

Izskatās, ka lielākais vairums tam piekrīt. http://stackoverflow.com/questions/77127/when-to-throw-an-exception

[codez]

 

Izskatās, ka lielākais vairums tam piekrīt. http://stackoverflow.com/questions/77127/when-to-throw-an-exception

Visvairāk balsu saņēmusī atbilde:

 

 

Example 2: say I have another function which examines a List<> and returns true if its length is more than 50, and false if the length is less. This function asks the question, "Does this list have more than 50 items?" But this question makes an assumption - it assumes that the object it is given is a list. If I hand it a NULL, then that assumption is false. In that case, if the function returns either true or false, then it is breaking its own rules. The function cannot return anything and claim that it answered the question correctly. So it doesn't return - it throws an exception.

 

Tātad, ja ir funkcija, kurai ir kaut kas jāizdara, vai jāatgriež un tā nevar atgriezt ne to, ko vajag, ne izdaarīt to, ko vajag, tad loģiski ir mest eksepšanu.

Manā piemērā:

$account=Model_Account::auth();

Šeit Model_Account::auth() atgriež ielogotā lietotāja kontu. Tāds ir tiešais funkcijas uzdevums. Bet, ja viņa to izdarīt nevar, viņa met eksepšanu.

 

$account->decMoney() - funkcija, kas samazina naudas daudzumu. Ja viņa to izdarīt nevar, vienalga kādu iemeslu dēļ, nav db konekcija, nepietiek nauda, utt. viņa met eksepšanu.

 

Sakarā ar šo tēmu vēl lasīju best practice citās valodās, jo PHP ar eksepšanu lietošanu ir pašvaki.

Atradu daudz piemēru, kur eksepšanu lieto gan datu validācijai, gan, ja lietotājs nav ielogojies pie darbības, kur lietotājam jābūt ielogotam.

http://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

[codez]

Īsāk nenozīmē saprotamāk, saprotamāk nenozīmē īsāk.

Bet īsāk nozīmē īsāk un saprotamāk nozīmē saprotamāk.

Kā jau te tika minēts, Exceptions izmanto izņēmumsituācijām, nevis biznesa loģikas kontrolei.

Manos piemēros eksepšani nav izmantoti tiešai biznesa loģikas kontrolei, bet gan vietās, kur tālāka biznesa loģikas izpilde nav iespējama, notiek izpildes pārtraukšana.

Piemēram, ja vietā, kur tiek noņemta nauda (funkcijā decMoney), labāk ir pārbaudīt vai nauda pietiek, lai nekādos apstākļos nevarētu rasties situācija, ka biznesa loģika tiek izpidlīta tālāk un kaut kur ierakstās negatīva summa. Tātad, ja decMoney() metīs eksepšanu uz šādu nepieļaujamu situāciju, tad tas tiks pilnībā nodrošināts, ja vien kāds speciāli nepārķers tieši to eksepšanu, lai izpildītu biznesa loģiku tālāk.

 

Nesaku, ka ar Exceptions nevar panākt līdzīgu rezultātu, bet... arī ar GOTO var daudz ko izdarīt.

Ir daudz vietu, kur exceptionus tiešām var izmantot greizi, tāpat kā goto.

Bet ir vietas, kur arī goto lietošana tiek uzskatīta par normālu, piemēram, breakot n-kāršo ciklu

 

http://stackoverflow.com/questions/1257744/can-i-use-break-to-exit-multiple-nested-for-loops

for(..
  for(..
    for(..
      if (..) {goto breakCycle;}
    }
  }
}
breakCycle:
 

http://stackoverflow.com/questions/1257744/can-i-use-break-to-exit-multiple-nested-for-loops

 

 

Taču, vai Tu zini, ko nozīmē uzturēt ātri un pa savam izveidotu sistēmu un ieviest tajā izmaiņas?

Pēdējais lielais projekts, kuru vadu, ir būvēts izmantojot tieši šādu praksi un projekts ir liels (vairāk kā 100k rindiņas koda, neskaitot 3rd party bibliotēkas), to uztur vairāki cilvēki un nekādas problēmas ar šo praksi nav radušās. Tieši pretēji, nav vairs situācijas, kad kāds kaut ko aizmirst pārbaudīt/validēt vai izpildās kāda darbība, kas nedrīkstēja izpildīties, jo nav visi pieļaujamie apstākļi. Un tas ir tāpēc, ka visa maģija notiek automātiski.

Edited March 11, 2013 by codez

[php newbie]

Ja sistēma ir tiešām ļoti liela un sarežģīta kur lielāka daļa funkciju ir black box. Loģika aiziet tik dziļi ka visu novalidēt nav reāli.

Teiksim ja tas $account->decMoney() izsauc vēl 5 funkcijas katra no kurām izsauc vēl 1-5 funkcijas, katra no kurām izsauc vēl.... *we need to go deeper*.  

Bet nu maziem projektiem es eksepšonus izmantotu tiešām kādu anomālu kļūdu izķeršanai. Teiksim db konekcija, vai kādas bibliotēkas koda izsaukumam.

[F3llony]

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

 

Un pēdejie pāris codez komentāri vismaz man, par nožēlu un pārsteigumu, pierādija, ka codez praktiskās pieredzes nav vairāk, kā pirmā kursa studentam. Da i teorētiskās iemaņas nav diez ko daudz labākas. 

 

Līkas rokas un nespēja izsekot programmas plūsmai nav arguments nepareizu konstrukciju lietošanai. Un pie kājas, vai tavā pēdējā lielajā projektā ir 100 vai 100 000 vai 1 000 000 rindiņu. Katru no šīm rindiņām var uzrakstīt vai nu caur pakaļu vai nu pareizi. Ja tavs pasūtitājs izdomās tavu kodu nodot auditam, viņi tur aiz smiekliem pielaidīs bikses un kāds labākajā gadījumā zaudēs darbu. Ja ne, jāpauž dziļa līdzjūtība tiem nabaga deviem, kam šis sūds būs jādebugo bez first-hand pieredzes tādā siena zārda arhitektūrā, kur tāds jēdziens kā normāla, pakāpeniska programmplūsma vispār neeksistē. Un es goda vārds gribētu zināt, kurš idiots par to tavu projektu maksā.

 

Un vēl - vai pilnīgi citas valodas (C++) loģikas un argumentu pielāgošana PHP ir ar kādu slēptu domu? Jo, piemēram, PHP break pieņem pakāpes, Tas dotneta raksts ir vispār ārpus konteksta un nepasaka neko tādu, kas norādītu uz tavas "idejas" kaut vai attālinātu pareizību vai priekšrocību. Te vispār visā topikā nav neviena paša argumenta, kāpēc exceptionus būtu labāk, kā normālu būla un datuplusmās loģiku. Lai gan norādīt uz neesošām priekšrocībām varētu būt diezgan pagrūti. Vai arī codez domā, ka mēs te visi esam pirmziemnieki lohi, kas nekad neko citu, kā džabaskriptu un php nav redzējuši?...

Edited March 11, 2013 by F3llony

[php newbie]

ok, bet tad microsoft un oracle džeki visu nepareizi sakodejuši :(

[F3llony]

Parādi man kādu Oracle vai MS koda gabalu, kur izņēmumi tiek lietoti kam citam, kā anomāliju apstrādei? E.G arhitektūras bāzē? 

[php newbie]

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.

 

[e-remit]

Parādi man kādu Oracle vai MS koda gabalu, kur izņēmumi tiek lietoti kam citam, kā anomāliju apstrādei? E.G arhitektūras bāzē? 

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