Nagy fg kilépési pontjai
2017-03-21T14:41:27+01:00
2017-03-22T10:35:50+01:00
2022-07-21T14:37:02+02:00
  • Én csinálnék egy olyan osztályt, ami két dolgot tartalmaz. 

    1. hibalista,
    2. visszatérési érték, az object amit vissza akarsz kapni.

    Ez a rész csak simán ellenőrizget:
     if (TO == null)
     {
         success = false;
         messageList.Add("Nincs megadva TO");
         
     }
     if (BCCList.Count()==0)
     {
         success = false;
         messageList.Add("Nincs elérhető BCC lista");
       
     }

    Ezt kiemelném egy method-ba, ami a speckó osztályban tölti fel a hibalistát ahogy kell.

    Amikor a metódus visszatér megnézed, hogy a hibalista üres-e. Ha nem üres, akkor továbbítod a hibákat ahová kell. 

    Ha üres, akkor megcsinálod a  
    emailList= ....
     Email.send();
    részeit...

    Most is valami hasonlót látok itt, mert van egy messageList, amibe üzeneteket pakolászol be.. Exception-okat én sem használnék, ha nem muszáj.

    Sőt van ott neked egy ReturnClass-od is már, így viszont csak azt kell betolnod egy metódusba, ami megcsinálja az ellenőrzéseket. Az alapján pedig eldöntöd, hogy végrehajtásra kerülhetnek-e a Send és egyéb metódusok... 

    Szerintem az, hogy 4, vagy 5 if vizsgálat történik már lényegtelen, az if belsejébe úgy sem fog bemenni, ráadásul a vizsgálatok egy külön metódusban lesznek... 

    Sőt igazából ezt a részt is 
     emailList= ....
     Email.send();
    kilehetne szervezni másik metódusba.
    Mutasd a teljes hozzászólást!
  • Több kilépési pont a függvényében: nehezebb debuggolni, módosítani, erőforrások maradhatnak felszabadítatlanul

    Amelyik nyelvben van try..finally, ott ez nem igaz. A "goto vege"-vel teleszórt kód egy fikarcnyival se könnyebben debugolható és módosítható, mint a return-nel teleszórt kód. A try..finally blokk explicit jelzi, hogy itt bizony a végén takarítás lesz, míg a függvény végén ott figyelő címke kevésbé egyértelmű jelentésű.
    Mutasd a teljes hozzászólást!
  • Alapvetően az a gond, hogy az alternatívák elfogadhatatlanok:
    o Egymásbaágyazott if-ek: nehezen átlátható, karbantarhatatlan
    o Duplikált kód: a szakma megcsúfolása
    o Több kilépési pont a függvényében: nehezebb debuggolni, módosítani, erőforrások maradhatnak felszabadítatlanul
    o Kivételek: akkor jók, ha a hibakezelés annyiból áll, hogy 'na jó, stack-trace, aztán kilépünk', egyébként nehézkes, erőltetett
    Mutasd a teljes hozzászólást!
  • Egy fél pillanatig elhittem h komolyan gondoltad.
    nem tesz jot ez az antialkoholista világnézet 
    Mutasd a teljes hozzászólást!
  • Szerintem itt igazából az a kérdés, hogy ezek az ellenőrzések a felhasználó kedvéért vannak benne (tehát hogy ő jól vitte-e be az adatot), vagy a programozó kedvéért (elkapni a programhibákat, mielőtt nagyobb kárt okoznak). Az első esetben van értelme listába gyűjteni a problémákat, de akkor erre egy kiemelt validációs kód kéne, amit le tudsz futtatni a tényleges műveletvégzés előtt. Így ha hülyeséget akar csinálni a felhasználó, azt kulturáltan közölni tudod vele, mielőtt bármi is változna a rendszerben. Ha viszont az ellenőrzés azért van benne, mert a hívó kód elronthat valamit, akkor egyszerűen az első talált hibánál dobni kell egy kivételt, így a többi kód természetesen nem fog lefutni. (Nyilván a lezárandó erőforrásokat using vagy try-finally használatával le kell zárni kivételes esetben is.)
    Mutasd a teljes hozzászólást!
  • Igen, ez C#.
    Ez egy összefogó függvény. Lehet benne jó néhény LINQ sor, pl az első megnézi, hogy van-e a mai napra bejegyzés, ha nincs akkor nem megy tovább a többi LINQ sorra, hanem visszatér a hibaüzenettel. Tehát összefogja a feladatokat, amik külön függvényekben vannak megírva. És elemzi a visszatérési értékeket.
    Mutasd a teljes hozzászólást!
  • Ez a throw-os vezérlésátadás nagyon nagy taknyolásnak tűnik nekem. Valahogy mindenképp el kéne kerülni.

    Az lenne a kérdésem, hogy ha egy függvény több dolgot csinál, mielőtt visszatér

    Lehet, hogy épp ez a gond: túl sok mindent csinál a függvényed. Lehetne például egy validációs függvény, ami csak végignézi a paramétereket, és megfelelően formázott hibaüzenetek listáját adja vissza. Ha ez nem talál hibát, akkor mehet a tényleges küldés egy másik függvényben. Ez a küldő függvény is kell, hogy ellenőrizze a bemenetét, de itt már nem kell figyelni a barátságos hibaüzenetre, mert ha a validáció elmaradt, az amúgy is a programozó hibája. .NET-hez annyira nem értek, de Javában erre van az IllegalArgumentException, valami hasonló lehet jó itt is.
    Mutasd a teljes hozzászólást!
  • A programnyelv ránézésre C#-nak tűnik. Ott ugyan van goto, de az erőforrás-felszabadításra nem az való, hanem a try-finally (vagy ha az erőforrás támogatja, a using).
    Mutasd a teljes hozzászólást!
  • Normálisan erre való a GOTO, de lehet, hogy ebben a nem-mondtad-milyen programnyelvben nincsen.

    public bool EmailSending(.......) { if (to==null || to.equals("")) { errstr= "Nincs címzett!"; errcode= 1; goto RETURN; } if (subject==null || subject.equals("")) { errstr= "Nincs tárgy!"; errcode= 2; goto RETURN; } ... RETURN: naplózás, debuggolás, erőforrás-felszabadítás }
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Az lenne a kérdésem, hogy ha egy függvény több dolgot csinál, mielőtt visszatér, hogy oldanátok meg a visszatérést, ha az egyes pontok után megvizsgáljátok, hogy mehet-e tovább. A visszatérési értékben benne van a sikeresség és a lehetséges hibalista, valamint a visszatérési adat.
    Ezt én így oldottam meg, a saját exception azért van, hogy a sima exception hibaüzenete ne zavarjon be a hibalistába.

    ublic bool EmailSending(.......) { bool success = true; List<string> messageList=new List<string>(); List<string> emailList=new List<string>(); try { if (TO == null) { success = false; messageList.Add("Nincs megadva TO"); throw new MyException(); } if (BCCList.Count()==0) { success = false; messageList.Add("Nincs elérhető BCC lista"); throw new MyException(); } emailList= .... Email.send(); messageList.Add("Sikerees email küldés"); } catch (MyException) { } catch (Exception ex) { success = false; } // Itt állítom össze a nagyobb osztályt, ami visszamegy a felületre. // Vagy visszamegy a success. Ha ez true, akkor van EmailList, ha false, akkor ez üres. return ReturnClass(){ Success=success, Message=messageList, EmailList=emailList } } public class ReturnClass : Response { public List<string> EmailList { get; set; } } public class Response { public bool Success { get; set; } public List<string> Message { get; set; } }
    Mutasd a teljes hozzászólást!
abcd