[Java] Missing return statement

[Torrentus]

Beste Tweakers,

Ik probeer (o.a.) onderstaande klasse te compilen, maar krijg dan de fout 'missing return statement' op regel 19.

Java:

public Kamer checkin(String wachtwoord, String naamgast){
        if (getVrijeKamer() != null){ //controleer op vrije kamers
                if(getWachtwoord().testWoord(wachtwoord)){//controleer wachtwoord
                    Gast nieuwegast = new Gast(naamgast); //aamaken nieuwe gast
                    if (this.getKamer(naamgast) == null){ //controleer of Gast al ingecheckt is.
                            nieuwegast.checkin(getVrijeKamer()); //Gast object laten weten in welke kamer die zit
                            getVrijeKamer().setGast(nieuwegast); //Kamer object laten weten welke gast hij bezit
                        } 
                    else {
                            return null; //gast al ingecheckt
                        }
                } 
                else {
                    return null; //wachtwoord fout
                }
        } 
        else {
                    return null;//hotel vol
        }
    }

Als ik er gewoon een extra return null in gooi voor na de sluitende accolade op regel 19 compiled hij wel, maar ik kan niet beredeneren waarom die extra return daar thuishoort?

Kan iemand me dat toelichten?

[Wildy]

Mist de if lus op regel 5 niet een return value?

[Anoniem: 288692]

Na regel 7 dien je ook een iets te returnen. Anders gaat hij door tot het einde wat op regel 19 is waar je dus uiteindelijk niets returned.

[azerty]

Spuit 11: te laat xD

Zoals Wildy & HerrBohm zeggen.

[jvo]

Er hoort altijd een return op de laatste regel te staan. Edit: Dat is natuurlijk niet helemaal waar en hier ook niet het probleem. Zelf ga ik liever nog voor deze variant qua opbouw:

Java:

Kamer test() {
    if (!a) return null;
    if (!b) return null;
    if (!c) return null;
    return result;
}

In jouw geval dus:

Java:

public Kamer checkin(String wachtwoord, String naamgast){
    if (getVrijeKamer() == null) return null; // hotel vol

    if (!getWachtwoord().testWoord(wachtwoord)) return null; // wachtwoord fout

    Gast nieuwegast = new Gast(naamgast); // aanmaken nieuwe gast
    if (this.getKamer(naamgast) != null) return null; // gast all ingescheckt

    Kamer kamer = getVrijeKamer();
    nieuwegast.checkin(kamer); //Gast object laten weten in welke kamer die zit
    kamer.setGast(nieuwegast); //Kamer object laten weten welke gast hij bezit
    return kamer;
}

Enfer schreef op maandag 24 september 2012 @ 14:10:
[...]


Dus

code:

...

Compileert ook niet?

Jawel, was iets te algemeen verwoord. Inmiddels aangepast.

[ Voor 104% gewijzigd door jvo op 24-09-2012 14:20 ]

[Enfer]

jvo schreef op maandag 24 september 2012 @ 14:09:
Er hoort altijd een return op de laatste regel te staan. Het volgende compileert ook niet:
-code-

Dus

code:

public String toString(){
    if( a ){
        return "a";
    } else {
        return "not a";
    }
}

Compileert ook niet?

---

TS: let eens goed op wat je returnt als een gast nog niet ingecheckt is..

[ Voor 54% gewijzigd door Enfer op 24-09-2012 14:17 ]

[Johnny]

De return null die je nu overal hebt staan kun je beter vervangen met throw Exception() en dan de aanroep van deze methode in een try/catch zetten.

Je gebruikt nu null voor verschillende fouten, maar de rest van je applicatie weet niet wat er mis ging. Met excepties kan je op een eenvoudige manier (dit is ook de juiste/aanbevolen manier in Java) een gedaileerde foutmelding doorgeven aan de gebruiker (of logbestanden).

http://docs.oracle.com/ja.../exceptions/throwing.html

[CodeCaster]

@Johnny: ik zou geen exceptions gebruiken voor dergelijke applicatielogica. De "checkin"-functie doet eigenlijk ook veel te veel.

[ Voor 4% gewijzigd door CodeCaster op 24-09-2012 14:20 ]

[epic007]

Inderdaad kan er aan de logica wel wat verbeterd worden (wachtwoord al checken voordat je deze functie aanroept bijvoorbeeld).
Ik vind hem zo iig al een stuk leesbaarder:

Java:

public Kamer checkin(String wachtwoord, String naamgast)
{
  if (!this.getWachtwoord().testWoord(wachtwoord))
    return null; // wachtwoord fout

  if (this.getKamer(naamgast) != null) 
    return null; // gast al ingechecked

  
  Kamer vrijeKamer = getVrijeKamer();

  if (vrijeKamer != null) {
    Gast gast= new Gast(naamgast); //aamaken nieuwe gast
    gast.checkIn(vrijeKamer);
    vrijeKamer.setGast(gast);
  }

  return vrijeKamer; // kan ook null zijn
}

Zoals JVO hierboven dus..

[alex3305]

Waarom geen Exceptions? Gast al ingecheckt, wachtwoord fout en hotel vol zijn weldegelijk verschillende fouten die kunnen voortkomen uit het proces. Daarbij is het natuurlijk voor de eventuele front-end wel handig om te weten wat er daadwerkelijk mis is gegaan. Ik denk dus dat zoiets als throw new Exception("Wachtwoord fout"), geen overbodige luxe is.

[Bartjeh]

epic007 schreef op maandag 24 september 2012 @ 14:22:
Inderdaad kan er aan de logica wel wat verbeterd worden (wachtwoord al checken voordat je deze functie aanroept bijvoorbeeld).
Ik vind hem zo iig al een stuk leesbaarder:

Java:

public Kamer checkin(String wachtwoord, String naamgast)
{
  if (!this.getWachtwoord().testWoord(wachtwoord))
    return null; // wachtwoord fout

  if (this.getKamer(naamgast) != null) 
    return null; // gast al ingechecked

  
  Kamer vrijeKamer = getVrijeKamer();

  if (vrijeKamer != null) {
    Gast gast= new Gast(naamgast); //aamaken nieuwe gast
    gast.checkIn(vrijeKamer);
    vrijeKamer.setGast(gast);
  }

  return vrijeKamer; // kan ook null zijn
}

Leesbaarder en allicht een stuk beter te testen ook.

[Haan]

Het hele issue, is dat de checkin method meer doet dan het zou moeten doen. Dus exceptions introduceren is alleen maar symptoombestrijding. Exceptions gebruiken voor business logica wijst vrijwel altijd op een verkeerd ontwerp, wat in dit geval ook klopt.

Een method die checkin heet, moet alleen iemand inchecken. Voordat deze functie wordt aangeroepen moeten de randvoorwaarden al gecheckt zijn.

[Janoz]

Wachtwoord is inderdaad niet de verantwoordelijkheid van deze methode. Maar het afhandelen van een vol hotel of het al ingecheked zijn van de gast lijkt me helemaal niet zo vreemd om af te handelen middels een exception. Het is eigenlijk maar net hoe je exceptionele flow definieert. Juist dit soort (binnen deze methode) unrecoverable fouten (je kunt binnen deze methode immers niet een kamer bij gaan bouwen) zou ik niet terug gaan geven met een gefabriceerde returncode welke je binnen de hele aanroepstack terug moet geven. Juist een exception gooien zorgt ervoor dat je code veel cleaner blijft en dat je de daadwerkelijke foutafhandeling kunt afhandelen op het niveau waar dat ook mogelijk is (een pagina of popup met daarin de melding dat de gast al ingechecked is)

[alex3305]

Dat dus. Neemt niet weg dat een Exception, zoals de naam ook al zegt een uitzondering is in de normale flow van het programma. Dat een gast al ingechecked is of dat er geen kamers meer beschikbaar zijn lijkt mij toch echt een uitzondering op de gehele flow.

Ook vind ik het, mits op de juiste manier gebruikt, een hele mooie manier om foutmeldingen door te kunnen gooien naar de UI. Dit zou ik dan zelf wel op een andere manier doen dan met platte tekst - bijvoorbeeld een constante met een vaste waarde - omdat je anders problemen kunt krijgen met inconsistentie of vertalingen.

[Haan]

@Janoz: Klopt, maar alle checks die gedaan worden zijn niet echt uitzonderingen, maar checks op situaties die in een normale toestand prima voor kunnen komen.

Waar bijvoorbeeld wel goed een exception gegooid zou kunnen worden, is de setGast method van de Kamer, mocht het per ongeluk gebeuren dat twee Gasten tegelijk dezelfde kamer willen inchecken.

edit: het komt er dus inderdaad op neer wat je als normaal beschouwt, en wat als uitzondering

[ Voor 13% gewijzigd door Haan op 24-09-2012 14:54 ]

[Janoz]

Mwah. Ik vind het inchecken terwijl het hotel vol is, of het inchecken van een gast welke al ingechecked is redelijk uitzonderlijk. Daarnaast, als je het al eerder zou checken? Hoe zou je die methode dan noemen? Ik ga er eigenlijk een beetje van uit dat we hier te maken hebben met de service methode die juist die dingen expliciet controleert. De interface is dan erg clean aangezien de methode gewoon de kamer van de gast terug geeft, of wanneer dat niet lukt een exception welke aangeeft waarom dat niet gelukt is. Een null retourneren zegt helemaal niks over waarom het fout gegaan is, en als je vervolgens allemaal returncodes gaat verzinnen om maar te voorkomen dat je een exception gooit dan ben je in mijn ogen verkeerd bezig.


Maar aan de andere kant verwacht ik ook dat uberhaupt het starten van de checkin usecase niet meer mogelijk is als het hotel vol is (en de exception dus alleen optreed wanneer de laatste kamer net vergeven is, met daarbij de aanname dat de getVrijekamer methode threadsafe is).

[Dars123]

Dit is vast geen produktiecode, maar een probeersel toch?

[Hydra]

jvo schreef op maandag 24 september 2012 @ 14:09:
Er hoort altijd een return op de laatste regel te staan. Edit: Dat is natuurlijk niet helemaal waar

Nee, het is gewoon helemaal niet waar.

alex3305 schreef op maandag 24 september 2012 @ 14:23:
Waarom geen Exceptions? Gast al ingecheckt, wachtwoord fout en hotel vol zijn weldegelijk verschillende fouten die kunnen voortkomen uit het proces. Daarbij is het natuurlijk voor de eventuele front-end wel handig om te weten wat er daadwerkelijk mis is gegaan. Ik denk dus dat zoiets als throw new Exception("Wachtwoord fout"), geen overbodige luxe is.

Dat is gewoon niet waar exceptions voor bedoeld zijn. Die zijn voor uitzonderingen. Dat een wachtwoord fout is is geen uitzonderingssituatie, dat is gewoon een onderdeel van je normale workflow.

[ Voor 57% gewijzigd door Hydra op 24-09-2012 18:22 ]

[alex3305]

Ben ik het niet mee eens, dus ik denk dat dat een punt is were we have to agree to disagree. Daarnaast kun je veel handige trucjes met Exceptions uitvoeren om makkelijk foutberichten door te geven naar de UI van je applicatie.

[Hydra]

alex3305 schreef op maandag 24 september 2012 @ 18:27:
Ben ik het niet mee eens, dus ik denk dat dat een punt is were we have to agree to disagree.

Nee hoor, je hebt het gewoon fout:

An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions.

Dat is de officiele 'java' definitie van een exception waar iedere fatsoenlijke Java developer zich aan zal houden. Dat een wachtwoord niet goed is, is geen uitzondering op de "normal flow of the program's instructions". Als bij ons in een peer review zo iets naar voren komt mag je het mooi gaan fixen. Exceptions zijn bedoeld voor situaties die voor kunnen komen maar niet bij de normale flow van een programma horen, dus het niet kunnen openen van een file of het geen verbinding kunnen maken op een endpoint waar je een server verwacht.

[Soultaker]

Wat de normale flow is lijkt me tot op zekere hoogte wél discutabel. Je schrijft immers exception handling code voor situaties waarvan je je kunt voorstellen dat die kunnen voorkomen, en hoe je ze afhandelt is relevant voor de program flow.

Er is ook precedent voor het raisen van een exception als een wachtwoord verkeerd is; JDBC drivers doen dat bijvoorbeeld ook. Je hebt ook niet zoveel keuze in Java als je out-of-band gedetailleerde foutinformatie wil teruggeven, aangezien reference parameters of multiple return values niet bestaan.

Ik vraag me af wat de oplossing is die jij voorstelt?

[Jegorex]

Soultaker schreef op maandag 24 september 2012 @ 20:56:
Je hebt ook niet zoveel keuze in Java als je out-of-band gedetailleerde foutinformatie wil teruggeven, aangezien reference parameters of multiple return values niet bestaan.

Ik vraag me af wat de oplossing is die jij voorstelt?

Je kunt wel een reference object meegeven waar je de parameters in stopt.
Maar ik ben het met je eens dat een exception throwen de netste oplossing is.

[alex3305]

Hydra schreef op maandag 24 september 2012 @ 18:31:
[...]

Dat is de officiele 'java' definitie van een exception waar iedere fatsoenlijke Java developer zich aan zal houden. Dat een wachtwoord niet goed is, is geen uitzondering op de "normal flow of the program's instructions". Als bij ons in een peer review zo iets naar voren komt mag je het mooi gaan fixen. Exceptions zijn bedoeld voor situaties die voor kunnen komen maar niet bij de normale flow van een programma horen, dus het niet kunnen openen van een file of het geen verbinding kunnen maken op een endpoint waar je een server verwacht.

Een fout wachtwoord is ook een interruptie op de normale flow hoor . Want je verwacht dat de gebruiker het correcte wachtwoord invult. Dus het is zeker wel discutabel en zoiets zou ik niet fixen omdat jij iets anders vind.

[xzaz]

alex3305 schreef op dinsdag 25 september 2012 @ 00:10:
[...]

Een fout wachtwoord is ook een interruptie op de normale flow hoor . Want je verwacht dat de gebruiker het correcte wachtwoord invult. Dus het is zeker wel discutabel en zoiets zou ik niet fixen omdat jij iets anders vind.

Dus alles wat na de if komt is een interruptie in de normale flow?

Met andere woorden; er is maar 1 flow mogelijk, hij heeft of het wachtwoord goed of het wachtwoord fout. Bijde zijn normale flows. Een interruptie (exception) is wanneer het wachtwoord goed en fout is op het zelfde moment.

[ Voor 21% gewijzigd door xzaz op 25-09-2012 10:39 ]

[Woy]

Het is ook afhankelijk van de verantwoordelijkheden van de methode. In dit geval zou ik inderdaad zeggen dat de normale flow is dat het wachtwoord klopt.

Als je het nu puur over een Login methode o.i.d. zou hebben die gewoon een LoginResult terug geeft, dan kan het foutief invoeren van het wachtwoord inderdaad best normale flow zijn, en zou ik het ook zonder exception doen.

In dit geval zou ik zeggen dat de pre-condities zouden moeten zijn dat de gebruiker is ingelogd, en dat de kamer en het hotel waar in gechecked wordt nog vrij zijn. Als één van die condities faalt zou het IMHO inderdaad gewoon netjes zijn om een Exception te gooien.

jvo schreef op maandag 24 september 2012 @ 14:09:
Er hoort altijd een return op de laatste regel te staan. Edit: Dat is natuurlijk niet helemaal waar en hier ook niet het probleem. Zelf ga ik liever nog voor deze variant qua opbouw:

Nee dit is dus, zoals al genoemd, niet correct. Alle verschillende Code-paths dienen een return value te hebben ( Of een exception te gooien ) bij een non-void method.

[Hydra]

Soultaker schreef op maandag 24 september 2012 @ 20:56:
Wat de normale flow is lijkt me tot op zekere hoogte wél discutabel. Je schrijft immers exception handling code voor situaties waarvan je je kunt voorstellen dat die kunnen voorkomen, en hoe je ze afhandelt is relevant voor de program flow.

Ja, en dat een gewone gebruiker een verkeerd wachtwoord invoert (typfout ofzo) is geen exception maar gewoon een standaard check.

Er is ook precedent voor het raisen van een exception als een wachtwoord verkeerd is; JDBC drivers doen dat bijvoorbeeld ook. Je hebt ook niet zoveel keuze in Java als je out-of-band gedetailleerde foutinformatie wil teruggeven, aangezien reference parameters of multiple return values niet bestaan.

User wachtwoorden zijn een compleet andere situatie dan database wachtwoorden. Die staan ergens in een configfile meestal. Als dat fout gaat, dan is er iets grondig mis, en doet meestal je hele applicatie het niet. Als een user een typfout maakt dan is dat een onderdeel van je normale flow.

Ik vraag me af wat de oplossing is die jij voorstelt?

Een verkeerd database wachtwoord is net zoals een niet bereikbare database of een missende configfile gewoon een exception. Daar moet waarschijnlijk een beheerder aan te pas komen.

Woy schreef op dinsdag 25 september 2012 @ 10:58:
Het is ook afhankelijk van de verantwoordelijkheden van de methode. In dit geval zou ik inderdaad zeggen dat de normale flow is dat het wachtwoord klopt.

Ik snap niet hoe men er hier hemelsnaam op komt dat "de normale flow" geen IFs kent? Heb je wel eens een flowchart gezien? Daarin worden continue keuzes gemaakt. De normale flow is dat een wachtwoord goed of fout is, en in beide situaties ga je daar op een andere manier mee om (goed = ingelogd, fout = schermmelding met een "password vergeten?" link).

alex3305 schreef op dinsdag 25 september 2012 @ 00:10:
Een fout wachtwoord is ook een interruptie op de normale flow hoor . Want je verwacht dat de gebruiker het correcte wachtwoord invult. Dus het is zeker wel discutabel en zoiets zou ik niet fixen omdat jij iets anders vind.

Complete onzin dus. Een password-check is een onderdeel van de standaard workflow die volgt uit een user-story en beide mogelijkheden (of nog meer als je een aparte melding wil geven dat een username niet bestaat) zijn ook gewoon een normaal onderdeel van de flow.

Een database password dat fout is, wordt waarschijnlijk veroorzaakt door een fuck-up bij de deployment en zal door een beheerder gecorrigeerd moeten worden. Het is complete onzin om voor een simpele "klopt het password?" methode een exception te gaan gooien; een simple true-false is in de meeste gevallen genoeg.

Exceptions zijn bedoeld voor technische fouten; er is echt iets grondig mis. In princiepe zouden ze niet op moeten treden. Als je bijvoorbeeld een file dialog toont waarin een gebruiker een file selecteert en als je deze probeert te openen dit toch niet mogelijk is, dan is er een uitzonderingssituatie: die file bestaat maar kennelijk mag/kan je er niet bij, bijvoorbeeld als een andere programma dit al geopend heeft.

[ Voor 43% gewijzigd door Hydra op 25-09-2012 12:48 ]

[Woy]

Hydra schreef op dinsdag 25 september 2012 @ 12:41:
[...]
Ik snap niet hoe men er hier hemelsnaam op komt dat "de normale flow" geen IFs kent? Heb je wel eens een flowchart gezien? Daarin worden continue keuzes gemaakt. De normale flow is dat een wachtwoord goed of fout is, en in beide situaties ga je daar op een andere manier mee om (goed = ingelogd, fout = schermmelding met een "password vergeten?" link).

Ik zeg nergens dat normale flow geen if's kent ( En zie dat sowieso niet terug in dit topic ). Ik zeg alleen dat het afhankelijk is van wat de pre-condities zijn. Dat er ergens in het systeem een normale flow is voor het invoeren van het wachtwoord zegt niet dat dat binnen deze functie zo zou moeten zijn.

IMHO is het vooral fout als het zo is dat deze methode ook verantwoordelijk is voor het inloggen/controleren wachtwoord. Maar imho zou het heel normaal zijn als een checkin methode een exception gooit als er niet is ingelogd o.i.d.

Maar er valt natuurlijk niet zo veel over de rest van de structuur van het programma te zeggen zonder daar meer kennis van te hebben. Wie weet dat het wachtwoord al eerder in de applicatie is gevalideerd, en dat daar wel iets van een LoginResult op komt.

Als het hier normale flow zou zijn dat het wachtwoord verkeerd kan zijn, zou wat mij betreft aangeven dat er te veel verantwoordelijkheden in deze methode gelegd zijn.

[Hydra]

Woy schreef op dinsdag 25 september 2012 @ 12:57:
[...]

Ik zeg nergens dat normale flow geen if's kent ( En zie dat sowieso niet terug in dit topic ). Ik zeg alleen dat het afhankelijk is van wat de pre-condities zijn. Dat er ergens in het systeem een normale flow is voor het invoeren van het wachtwoord zegt niet dat dat binnen deze functie zo zou moeten zijn.

IMHO is het vooral fout als het zo is dat deze methode ook verantwoordelijk is voor het inloggen/controleren wachtwoord. Maar imho zou het heel normaal zijn als een checkin methode een exception gooit als er niet is ingelogd o.i.d.

Maar er valt natuurlijk niet zo veel over de rest van de structuur van het programma te zeggen zonder daar meer kennis van te hebben. Wie weet dat het wachtwoord al eerder in de applicatie is gevalideerd, en dat daar wel iets van een LoginResult op komt.

Als het hier normale flow zou zijn dat het wachtwoord verkeerd kan zijn, zou wat mij betreft aangeven dat er te veel verantwoordelijkheden in deze methode gelegd zijn.

Dat is wat anders. Als er ergens in het programma een check op PW gedaan wordt, en op een andere punt een dat wachtwoord toch niet klopt, dan is er ook echt iets mis. Danwel technisch, of iemand probeert binnen te komen in je systeem ofzo.

Ik ben het er wel mee eens dat het niet netjes is al die checks op die manier in 1 methode te doen, maar dat is hier ook niet zo relevant omdat het overduidelijk een probeersel was. In een productieapplicatie zou je het waarschijnlijk anders oplossen, eerst inloggen en pas later een kamer boeken. En als het perse in 1 keer moet, kan je ook prima een statusobject terugsturen met wat er precies mis is. Daar heb je geen Exceptions (met de hele stacktrace) voor nodig. Dat er voor exceptions een hele stacktrace opgebouwd wordt laat al duidelijk zien waarvoor ze bedoeld zijn. Aan het opbouwen van die stacktrace zit ook een overhead die in dit geval gewoon onnodig is.

Hoe dan ook gaat het throwen van Exceptions bij een resultaat dat je verwacht (je verwacht dat users typefouten maken bij het inloggen) tegen de Java conventies in.

[terje7601]

Hydra schreef op dinsdag 25 september 2012 @ 17:25:
Hoe dan ook gaat het throwen van Exceptions bij een resultaat dat je verwacht (je verwacht dat users typefouten maken bij het inloggen) tegen de Java conventies in.

Hoe verklaar je javax.security.auth.login.FailedLoginException dan? Uit de javadoc:

This exception is thrown by LoginModules if authentication failed. For example, a LoginModule throws this exception if the user entered an incorrect password.

[Webgnome]

terje7601 schreef op dinsdag 25 september 2012 @ 19:39:
[...]


Hoe verklaar je javax.security.auth.login.FailedLoginException dan? Uit de javadoc:

[...]

Strictly speaking verwacht je niet dat iemand zijn wachtwoord verkeerd intikt dus throw je een exception? of denk ik nou te simpel...

[Soultaker]

Hydra schreef op dinsdag 25 september 2012 @ 12:41:
User wachtwoorden zijn een compleet andere situatie dan database wachtwoorden. Die staan ergens in een configfile meestal.

Ik dacht al dat je dat ging zeggen, maar in grafische database frontends worden wachtwoorden ook gewoon door gebruikers ingetypt, en die worden dan via dezelfde API's meegegeven. Zie ook het voorbeeld van terje7601. Dat onderscheid is dus niet zo duidelijk als je het doet voorkomen.

De normale flow is dat een wachtwoord goed of fout is, en in beide situaties ga je daar op een andere manier mee om (goed = ingelogd, fout = schermmelding met een "password vergeten?" link).

Dat een bestand wel/niet bestaat kan net zo goed onderdeel zijn van de normale program flow. Bijvoorbeeld als ik een applicatie heb die eerst probeert user-specifieke settings uit de homedir van de gebruiker te lezen, waarbij 9 van de 10 keer dat bestand gewoon niet bestaat, en ik dus de bijbehorende FileNotFoundException afvang.

Je kunt eerst handmatig testen of het bestand bestaat, maar dat introduceert een race condition (met daarop alsnog kans op een exception) wat het mijns inziens tot een anti-pattern maakt.

Ik vraag me af wat de oplossing is die jij voorstelt?
Een verkeerd database wachtwoord is net zoals een niet bereikbare database of een missende configfile gewoon een exception. Daar moet waarschijnlijk een beheerder aan te pas komen.

Ik bedoelde: hoe zou jij in het voorbeeld van de TS terugcommuniceren naar de caller dat de operatie faalde omdat het wachtwoord niet klopte?

[Remus]

Hydra schreef op dinsdag 25 september 2012 @ 12:41:
Ja, en dat een gewone gebruiker een verkeerd wachtwoord invoert (typfout ofzo) is geen exception maar gewoon een standaard check.

Daar ben ik het niet mee eens. Het mag misschien 'normaal' zijn dat een gebruiker een verkeerde wachtwoord uitvoert, voor de betreffende code is het een afwijking van de normale gang van zaken. De normale gang van zaken is dat het wachtwoord wel goed is en dat de acties uitgevoerd mogen worden. De normale gang van zaken is dan dat alle acties correct zijn afgehandeld. Het verkeerd zijn van een wachtwoord kan in die situatie dus wel degelijk als exception beschouwd worden, en dat kan juist ook zijn voordelen hebben om alleen bij het voltooien van de acties een waarde te retourneren en in alle andere gevallen een exception te gooien.

Exceptions zijn bedoeld voor technische fouten; er is echt iets grondig mis. In princiepe zouden ze niet op moeten treden. Als je bijvoorbeeld een file dialog toont waarin een gebruiker een file selecteert en als je deze probeert te openen dit toch niet mogelijk is, dan is er een uitzonderingssituatie: die file bestaat maar kennelijk mag/kan je er niet bij, bijvoorbeeld als een andere programma dit al geopend heeft.

Exceptions zijn niet enkel en alleen voor technische fouten, dat is grote onzin. Exceptions zijn in principe voor alles wat voorkomt dat een methode zijn normale werk kan doen. Als dat normale werk is om een kamer toe te kennen aan een gast dan kan je dus situaties die voorkomen dat dat werk gedaan wordt als exception beschouwen. En nee, dat is niet altijd de beste keuze.

Hydra schreef op dinsdag 25 september 2012 @ 17:25:
[...]

Ik ben het er wel mee eens dat het niet netjes is al die checks op die manier in 1 methode te doen, maar dat is hier ook niet zo relevant omdat het overduidelijk een probeersel was. In een productieapplicatie zou je het waarschijnlijk anders oplossen, eerst inloggen en pas later een kamer boeken. En als het perse in 1 keer moet, kan je ook prima een statusobject terugsturen met wat er precies mis is. Daar heb je geen Exceptions (met de hele stacktrace) voor nodig. Dat er voor exceptions een hele stacktrace opgebouwd wordt laat al duidelijk zien waarvoor ze bedoeld zijn. Aan het opbouwen van die stacktrace zit ook een overhead die in dit geval gewoon onnodig is.

Een statusobject terugsturen is IMHO vaak omslachtiger en lelijker dan het gooien van een Exceptions. Exceptions houden je interface veel cleaner als het daadwerkelijk gaat om signaleren van dingen die de normale werking van een methode in de wegstaan. Het voorbeeld in de TS is daar bij uitstek een voorbeeld van. Als een methode nu als taak heeft te controleren of iemand is ingelogd, of om te controleren of aan bepaalde voorwaarden is voldaan, dan is een Exception inderdaad niet op zijn plaats.

Hoe dan ook gaat het throwen van Exceptions bij een resultaat dat je verwacht (je verwacht dat users typefouten maken bij het inloggen) tegen de Java conventies in.

Niet dus, maar ik zie graag een bron om mij van het tegendeel te overtuigen.

[ Voor 31% gewijzigd door Remus op 25-09-2012 20:44 ]

[Silentuz]

Wel grappig om te zien dat mensen zo kunnen discussieren over een klein stukje code

Dit is overigens een practicumopgave van het vak Programmeren 1 op de Universiteit Twente (Bachelor Technische Informatica). Exceptions komen pas bij Programmeren 2.

-edit- oplossing was natuurlijk nogal spuit11

[ Voor 30% gewijzigd door Silentuz op 26-09-2012 10:02 ]

[Hydra]

terje7601 schreef op dinsdag 25 september 2012 @ 19:39:
Hoe verklaar je javax.security.auth.login.FailedLoginException dan? Uit de javadoc:

Dat is een API, ze weten van te voren niet waar je 'em voor gaat gebruiken en of of een gebruiker z'n wachtwoord verkeerd intypt bij de normale flow hoort of niet dus daar moet een keuze in gemaakt worden.

Soultaker schreef op dinsdag 25 september 2012 @ 20:28:
Ik dacht al dat je dat ging zeggen, maar in grafische database frontends worden wachtwoorden ook gewoon door gebruikers ingetypt, en die worden dan via dezelfde API's meegegeven.

Ik begin hier een beetje moe van te worden. Als je het verschil niet snapt tussen een password in een config die fout is en een gebruiker (dus niet beheerder) die bij een login z'n password verkeerd intypt ben ik er wel klaar mee.

Zelfde geldt voor de rest van je post. Er zijn onverwachte situaties en situaties die bij de normale programflow horen. Voor de eerste gebruik je exceptions, voor de 2e een gewone check en een gewone melding aan de gebruiker.

Ik bedoelde: hoe zou jij in het voorbeeld van de TS terugcommuniceren naar de caller dat de operatie faalde omdat het wachtwoord niet klopte?

Je hebt een checkpassword methode en die geeft een boolean / message / statusobject terug en daar doe je in je frontend iets mee. Het voorbeeld van de TS is aan alle kanten fout maar niet omdat 'ie geen exceptions gooit.

Remus schreef op dinsdag 25 september 2012 @ 20:37:
Exceptions zijn niet enkel en alleen voor technische fouten, dat is grote onzin.

Leg me geen woorden in de mond, dat zeg ik niet. Ik probeer duidelijk te maken wat het verschil is, vooral wat betreft het password verhaal.

Ik ben verder klaar met deze discussie. Exceptions zijn bedoeld voor onderbrekingen in de normale program flow. Het is een manier voor een stuk code om te zeggen "ja hallo, ik weet het ook niet meer!". Als je ze gebruikt voor user password checks zoals beschreven ga je, IMHO, gewoon recht in tegen de Java conventions. Ben je het niet met me eens, prima, we hoeven niet samen te werken en als we dat wel hadden moeten doen had je het toch op mijn manier moeten doen

[Kajel]

Hydra schreef op woensdag 26 september 2012 @ 10:27:
Ik ben verder klaar met deze discussie. Exceptions zijn bedoeld voor onderbrekingen in de normale program flow. Het is een manier voor een stuk code om te zeggen "ja hallo, ik weet het ook niet meer!". Als je ze gebruikt voor user password checks zoals beschreven ga je, IMHO, gewoon recht in tegen de Java conventions. Ben je het niet met me eens, prima, we hoeven niet samen te werken en als we dat wel hadden moeten doen had je het toch op mijn manier moeten doen

Mooi verhaal, maar niemand spreekt je definitie van Exceptions echt tegen, men is het er enkel niet over eens wat "de normale program flow" is. Daar kun jij ook niet zomaar stellig antwoord op geven, want daar is blijkbaar geen eenduidige definitie voor.
Als Exceptions er enkel waren voor de situatie "ja hallo, ik weet het ook niet meer!", waarom vangen we dan heel specifieke named Exceptions af, en handelen we die af waarna het programma gewoon netjes doordraait? Blijkbaar weet je/het programma het wel, sterker nog, de Exception werd zelfs verwacht, en er is daarom code om die specifieke Exception af te handelen!

[xzaz]

In Java wordt ik sowieso gek van de exception afhandeling. En wordt naar mijn mening nog wel eens overused. Ik, persoonlijk, gebruik exceptions alleen op het moment dat er iets gebeurt wat niet kan gebeuren. Een fout wachtwoord kan gewoon gebeuren en dus zal ik geen exception gooien maar gewoon een melding 'fout wachtwoord'.

MAAR, dit is ook weer afhankelijk van de soort applicatie en de afhandeling van de exceptions en de logging daarvan. Voor services vang ik zo veel mogelijk op via exceptions om traces te krijgen en uiteindelijk om de programmatuur te debuggen en te verbeteren. In een Windows app zal ik dit niet doen. Het zijn uiteindelijk overwegingen die je moet maken.

[YopY]

Ik ben geen expert op het gebied van exceptions, maar 99% van de unchecked exceptions die ik afgehandeld zie worden doen niets meer dan een melding loggen. Soms wordt er een default value ingesteld als het bijvoorbeeld gaat om het parsen van integers of URLs, maar dat is ook alles wel.

Wat dat betreft vind ik Scala beter; elke exception (ook die uit Java) zijn unchecked, en als je toch een API hebt die exceptions gooit waar je wel wat mee kunt kun je die gewoon catchen en afhandelen. Maar dat terzijde.

[Waster]

xzaz schreef op woensdag 26 september 2012 @ 12:26:
In Java wordt ik sowieso gek van de exception afhandeling. En wordt naar mijn mening nog wel eens overused. Ik, persoonlijk, gebruik exceptions alleen op het moment dat er iets gebeurt wat niet kan gebeuren. Een fout wachtwoord kan gewoon gebeuren en dus zal ik geen exception gooien maar gewoon een melding 'fout wachtwoord'.

MAAR, dit is ook weer afhankelijk van de soort applicatie en de afhandeling van de exceptions en de logging daarvan. Voor services vang ik zo veel mogelijk op via exceptions om traces te krijgen en uiteindelijk om de programmatuur te debuggen en te verbeteren. In een Windows app zal ik dit niet doen. Het zijn uiteindelijk overwegingen die je moet maken.

Ik vind java fijner qua exceptions dan C# waar geen verschil is tussen checked en runtime exceptions. Hoe moet ik in C# brak gedocumenteerde exceptions vangen als ik data van een externe datasource opvang?

[90710]

Enfer schreef op maandag 24 september 2012 @ 14:10:
[...]


Dus

code:

public String toString(){
    if( a ){
        return "a";
    } else {
        return "not a";
    }
}

Compileert ook niet?

Nee, a is niet gedefinieerd.

[bwerg]

Ja, en die methode moet in een klasse staan en je mist een main-methode... lolbroek.

[RobIII]

90710 schreef op woensdag 26 september 2012 @ 19:51:
[...]

Nee, a is niet gedefinieerd.

Says who? Wie weet is 't wel een class member? Of er is wel meer mis met die code (zie bwerg hierboven), of je grapje is niet grappig

[ Voor 34% gewijzigd door RobIII op 26-09-2012 21:26 ]

[Remus]

xzaz schreef op woensdag 26 september 2012 @ 12:26:
In Java wordt ik sowieso gek van de exception afhandeling. En wordt naar mijn mening nog wel eens overused. Ik, persoonlijk, gebruik exceptions alleen op het moment dat er iets gebeurt wat niet kan gebeuren. Een fout wachtwoord kan gewoon gebeuren en dus zal ik geen exception gooien maar gewoon een melding 'fout wachtwoord'.

En hoe geef je die melding terug? Als je een layered architectuur hebt, dan zal je toch een mechanism nodig hebben om dergelijke meldingen van het punt van optreden naar (bijvoorbeeld) de user interface te krijgen, en daarbij zijn Exceptions toch vaak de meest simpele en effectieve methode om dit soort dingen over API boundaries te communiceren.

Hydra schreef op woensdag 26 september 2012 @ 10:27:
Leg me geen woorden in de mond, dat zeg ik niet. Ik probeer duidelijk te maken wat het verschil is, vooral wat betreft het password verhaal.

Ik leg je geen woorden in de mond, ik quote letterlijk wat je zegt: "Exceptions zijn bedoeld voor technische fouten" in Hydra in "[Java] Missing return statement"

[ Voor 22% gewijzigd door Remus op 29-09-2012 11:14 ]

[xzaz]

Remus schreef op zaterdag 29 september 2012 @ 11:11:
[...]

En hoe geef je die melding terug? Als je een layered architectuur hebt, dan zal je toch een mechanism nodig hebben om dergelijke meldingen van het punt van optreden naar (bijvoorbeeld) de user interface te krijgen, en daarbij zijn Exceptions toch vaak de meest simpele en effectieve methode om dit soort dingen over API boundaries te communiceren.

Gewoon een return Object maken met een status, exceptions zijn de makkelijke weg maar niet de mooiste. Als we zo excepties gaan gebruiken kunnen we de 'else' implementatie van de if, else weghalen en gelijk een exception throwen.

[Janoz]

Sorry hooor, maar in welke wereld is een wrapper met de daadwerkelijke returnwaarde gecombineerd met een status object een mooiere oplossing dan gewoon de methode terug laten geven wat hij terug hoort te geven en een mogelijke fout via een (checked) exception terug te geven?

[Soultaker]

Nou, dat lijkt me dus wel een geniale uitvinding. Eigenlijk zou élke functie dan zo'n status-object moeten retourneren. Zo'n status-object bevat dan een resultaat-veld en een fout-veld, en als het fout-veld niet null is, kan de caller beslissen op basis van het type van het object dat daar staat, om de fout op een bepaalde manier af te handelen, en voor niet-ondersteunde typen kan de methode het hele object gewoon retourneren naar zijn caller, totdat iemand 'm afhandelt.

Ik stel voor dat we die fout-objecten voor de duidelijkheid allemaal afleiden van een basisklasse, bijvoorbeeld NotAnExceptionError. Da's handig, want dan kun je ze wat gemeenschappelijke state meegeven, zoals een String die de fout beschrijft en een stacktrace die in de constructor gemaakt wordt, zodat je handig kunt zien waar de fout optrad als je die informatie naar een logbestand ofzo schrijft.

Enige probleem is dus dat je wel code moet hebben om na elke method call het status-object te inspecteren, een eventuele fout af te handelen, of te retourneren. Misschien kunnen we een Eclipse-plugin ofzo schrijven om dat hele proces te automatiseren. Dat kost wat moeite, maar het feit dat je dan geen lelijke exceptions meer hoeft te gebruiken, maar het toch het overwegen waard.

[Feanathiel]

Mwah, dan kom je weer terug in de richting van de oude Win32 api (richting GetLastError()). Heb ik het dan goed als je deze richting op wilt gaan?

C#:

AStatus a = a();
if(a.State != null) { return ...; }

BStatus b = b();
if(b.State != null) { return ...; }

CStatus c = c();
if(c.State != null) { return ...; }

return ...;

Lijkt mij in ieder geval minder fraai dan één exceptie te vangen:

C#:

try
{
    a();
    b();
    c();
}
catch( Exception d )
{
    Log(...);
    return ...;
}

return ...;

[Soultaker]

Ik denk dat je mijn suggestie serieuzer opgevat hebt dan hij bedoeld was.

[Feanathiel]

Ah, ik denk al.

Volgens mij moet je het gewoon per situatie (zoals altijd) bekijken hoe het daar het beste kan. Er is geen één beste manier. Moet dan ook niet geforceerd worden.

@Janoz:

[ Voor 7% gewijzigd door Feanathiel op 30-09-2012 21:49 ]

[Janoz]

Ach, in mijn opinie schiet iedereen in de 'excpetions are bad, mkay' pavlov reactie en worde vervolgens de meest ranzige statuscode constructies in elkaar gedraaid. Van voormalig C programmeurs is dat nog wel te verwachten (returncode == statuscode zit in hun systeem).

Als ik naar de reacties van Hydra kijk dan kan ik eigenlijk alleen maar concluderen dat hij datgeen wat eigenlijk enkel voor de system exceptions geldt, door trekt naar alle exceptions.

Tot slot reboot ik Feanathiels sarcasme detector even want die lijkt wat kuren te hebben

[ACM]

Janoz schreef op zondag 30 september 2012 @ 21:25:
Als ik naar de reacties van Hydra kijk dan kan ik eigenlijk alleen maar concluderen dat hij datgeen wat eigenlijk enkel voor de system exceptions geldt, door trekt naar alle exceptions.

Desalniettemin is het nog steeds verstandig na te gaan of iets onderdeel van de normale flow had moeten zijn of niet. Het is vaak wel onderdeel van die flow dat je controleert of het wachtwoord juist is. Dus waarom kan dan een 'nee, die is niet juist' niet op een andere manier gecommuniceerd worden dan dmv een Exception?

Exceptions zijn vziw nog altijd wel degelijk bedoeld voor uitzonderlijke situaties, ongeacht of je ze zelf hebt verzonnen of vanuit een library terugkrijgt. Wat echter vooral discutabel is, is wanneer iets nou uitzonderlijk is. Een databaseserver die niet beschikbaar is valt meestal onder uitzonderingen. Maar als je een applicatie hebt die juist de status van die database moet controleren, dan is het weer een heel ander verhaal... Dan test je tenslotte expliciet op het wel/niet bestaan van die database en verwacht je blijkbaar dat daar een 'ja, hij doet het' of 'nee, ik kom er niet op' melding uit komt en niet dat je 'ja hij doet het' of een exception bij nee krijgt.
In diezelfde lijn kan het prima ongebruikelijk zijn dat een wachtwoord niet klopt. Bij API's waar door externe client-applicaties tegenaangesproken wordt is het waarschijnlijk zeldzaam dat wachtwoorden niet kloppen, terwijl bij een site voor internet-nono's men waarschijnlijk met enige regelmaat hun gebruikersnaam in het wachtwoordveld probeert te herhalen of domweg vergeten is wat het wachtwoord was en er dan maar een paar probeert.
Bij die laatste applicatie zou ik niet direct naar Exceptions voor wachtwoordcontrole grijpen, maar het scheelt dat een login-procedure bij een site doorgaans sowieso wel losstaat van de rest van de applicatie, waardoor je e.e.a. sowieso helemaal in een losse flow hebt.

Afgezien van bovenstaand verhaal is het soms niet praktisch om het anders dan met Exceptions op te lossen. Als je kunt kiezen tussen een draconische oplossing met return values of een elegante met Exception, dan wordt het natuurlijk een ander verhaal.
Maar dan moet je tegelijkertijd ook bedenken of je applicatie-flow dan wel klopt. Als je niet een expliciet punt hebt waar de inlog-credentials geverifieerd worden, maar dat helemaal overlaat aan je Exception-flow, dan doe je mogelijk al iets heel anders fout
(En dat was natuurlijk een van de originele klachten over de code uit de topicstart)

[ Voor 5% gewijzigd door ACM op 01-10-2012 08:06 ]

[RayNbow]

Janoz schreef op zondag 30 september 2012 @ 17:29:
Sorry hooor, maar in welke wereld is een wrapper met de daadwerkelijke returnwaarde gecombineerd met een status object een mooiere oplossing dan gewoon de methode terug laten geven wat hij terug hoort te geven en een mogelijke fout via een (checked) exception terug te geven?

Omdat product-types cooler zijn dan sum-types?

[Hydra]

Janoz schreef op zondag 30 september 2012 @ 21:25:
Als ik naar de reacties van Hydra kijk dan kan ik eigenlijk alleen maar concluderen dat hij datgeen wat eigenlijk enkel voor de system exceptions geldt, door trekt naar alle exceptions.

Nee en nee. Ik zeg niet dat exceptions bad zijn (integendeel; tegenwoordig heeft een try-catch block geen extra overhead meer en is het opbouwen van een exception stacktrace ook niet zo 'zwaar' meer) of dat alle exceptions 'system exceptions' zijn (wat dat ook moge zijn): ik zeg dat een gewone user-login check geen uitzondering op de programmaflow is en het dus niet de bedoeling is dat je daar een exception voor gebruikt.

Waarom ik nogal klaar ben met de discussie is:
1. Mensen vinden kennelijk een verkeerd ingevoerd password iets dat niet bij een normale programflow hoort
2. Mensen grijpen de slechte code als voorbeeld aan van een methode waarin zoveel fout kan gaan dat exceptions de 'beste' manier zijn omdat je anders complexe statusobjecten moet maken.

Wat betreft 1: als je dat vindt ben je 'beyond help'. Wat betreft 2: die code is gewoon brak, een methode is voor 1 ding verantwoordelijk, niet voor 5. Refactoren die hap.

Exceptions zijn voor zaken waarvan je weet dat ze fout kunnen gaan maar die in het "dagelijks gebruik" als het goed is niet optreden. Dat is het idee achter exceptions: als het goed gaat treden ze nooit op. Typefouten van gebruikers zijn geen uitzonderingen, die komen om de haverklap voor.

[Janoz]

Ik focus niet specifiek op het voorbeeld en ben het helemaal eens dat de controle van een wachtwoord een methode is welke gewoon een true of een false terug kan geven (of een principal of null). Echter, in een situatie waarbij je voor een methode een bepaalde rol nodig hebt, lijkt me een exceptie juist veel duidelijker (desnoods afgedwongen middels een aspect of annotatie).

Jouw verhaal hoort bij het verhaal wat sun heeft over de unchecked exceptions (alhoewel die redenatie aangeeft dat IOException dan eigenlijk ook unchecked zouden moeten zijn). Situaties waar je binnen je programma eigenlijk weinig mee kunt. Je hebt echter ook genoeg situaties waarbij je lokaal geen idee kunt hebben wat er met een bepaalde fout situatie moet gebeuren, terwijl het op een andere plek in je programma wel duidelijk is. Juist wanneer je probeert de hoeveelheid verantwoordelijkheden van een stuk code terug te brengen zul je dit veel meer tegen komen.

[Hydra]

Janoz schreef op maandag 01 oktober 2012 @ 11:12:
Ik focus niet specifiek op het voorbeeld en ben het helemaal eens dat de controle van een wachtwoord een methode is welke gewoon een true of een false terug kan geven (of een principal of null). Echter, in een situatie waarbij je voor een methode een bepaalde rol nodig hebt, lijkt me een exceptie juist veel duidelijker (desnoods afgedwongen middels een aspect of annotatie).

Als je voor een methode ingelogd zou moeten zijn, maar dat toch niet bent (er is dus iets misgegaan), is dat inderdaad een moment om een exception te gooeien.

Jouw verhaal hoort bij het verhaal wat sun heeft over de unchecked exceptions (alhoewel die redenatie aangeeft dat IOException dan eigenlijk ook unchecked zouden moeten zijn). Situaties waar je binnen je programma eigenlijk weinig mee kunt. Je hebt echter ook genoeg situaties waarbij je lokaal geen idee kunt hebben wat er met een bepaalde fout situatie moet gebeuren, terwijl het op een andere plek in je programma wel duidelijk is. Juist wanneer je probeert de hoeveelheid verantwoordelijkheden van een stuk code terug te brengen zul je dit veel meer tegen komen.

Je trekt het nu heel breed en ik kan het dus onmogelijk met je oneens zijn, ik had het over een heel specifiek voorbeeld (userinvoer checks, en nog wel specifiek die van een password) waarvan het geen uitzonderingssituatie is als iemand daar een typfout in maakt.

[Janoz]

Ik heb het in dit topic dan ook nooit over het gooien van een exceptie bij de inlogcheck gehad, maar wel dat het vol zijn van het hotel of het al ingechecked zijn van de gast best legitieme redenen voor een exception kunnen zijn, terwijl dat best dingen kunnen zijn die 'dagelijks' voorkomen.

[xzaz]

Janoz schreef op maandag 01 oktober 2012 @ 11:21:
Ik heb het in dit topic dan ook nooit over het gooien van een exceptie bij de inlogcheck gehad, maar wel dat het vol zijn van het hotel of het al ingechecked zijn van de gast best legitieme redenen voor een exception kunnen zijn, terwijl dat best dingen kunnen zijn die 'dagelijks' voorkomen.

Als je de methode 'inchecken(Klant klant, Kamer kamer)' heb verwacht je dat daar een klant is die niet null is. Als dat gebeurt is er dus iets aan de hand in de normale flow van het programma. Hij zou immers nooit de methode kunnen uitvoeren als hij nog niet geauthoriseerd is. Dan zal ik me eigen exception gaan gooien.

Dus niet wanneer die bezig is met inloggen en gelijk een exceptie naar ze hoofd krijgt wanneer die fout is ingelogd. Gooi er anders gelijk een 500 HTTP header tegen aan!

Edit: ik ben het dan ook eens met Hydra

[ Voor 12% gewijzigd door xzaz op 01-10-2012 11:46 ]

[Hydra]

Janoz schreef op maandag 01 oktober 2012 @ 11:21:
Ik heb het in dit topic dan ook nooit over het gooien van een exceptie bij de inlogcheck gehad, maar wel dat het vol zijn van het hotel of het al ingechecked zijn van de gast best legitieme redenen voor een exception kunnen zijn, terwijl dat best dingen kunnen zijn die 'dagelijks' voorkomen.

Ligt eraan waar dat gebeurt. Wij hebben toevallig een klant waar beschikbaarheidschecks gedaan worden en dat is gewoon een 'vraag' aan een database waar de code een ja/nee antwoord op krijgt (om precies te zijn, een lijst van accommodaties die beschikbaar) zijn.

Als je die lijst ophaalt en er 0 accommodaties zijn, is dat geen reden een exception te gooien. Maar als je 20 minuten later boekt op een accommodatie die al weg is ondertussen dan wordt er wel een exception gegooid omdat dat deel van het systeem daar verder niks mee kan.

[Janoz]

Mits dat de vraag is natuurlijk. Ik zit hier juist met een systeem wat een bepaalde mutatie moet doorvoeren waarbij op veel stappen iets mis kan gaan. Dat was gedaan met een statuscode waardoor de code leek op:

code:

if (status == OK) status = doStepOne();
if (status == OK) status = doStepTwo();
if (status == OK) status = doStepThree();
return status

Dit herschrijven naar een systeem waarbij een service exception met de fout status code maakte de code ineens een stuk leesbaarder.

[Hydra]

Janoz schreef op maandag 01 oktober 2012 @ 12:37:
Mits dat de vraag is natuurlijk. Ik zit hier juist met een systeem wat een bepaalde mutatie moet doorvoeren waarbij op veel stappen iets mis kan gaan.

Zoals ik al eerder aangegeven heb: de code van de TS is nogal een rommeltje. De oplossing zijn geen Exceptions, de oplossing is refactoring. Hoe dat er precies uit moet gaan zien kan ik zo ook niet zeggen want ik weet niks over de rest van de applicatie.

Als dit een webapplicatie zou zijn zou je m.i. ook gewoon via ajax-calls de status van de verschillende zaken (is een user ingelogged, is er een kamer beschikbaar, etc.) ophalen en als zodanig in de UI duidelijk weergeven. Als er dan daadwerkelijk een boeking gedaan moet worden kom je in een bookings-wizard waarin je stap voor stap door het proces geleidt wordt. Dan wordt gecheckt of je ingelogged bent (en krijg je de mogelijkheid jezelf te registreren), krijg je de mogelijkheid om nog even te checken dat je idd. de goeie kamer hebt, etc. Je begint met het ontwerp van die UI en op basis daarvan knoop je je business layer en de UI aan elkaar.

Jouw voorbeeld kan ik niks over zeggen aangezien het niet duidelijk is dat het uitzonderlijk is of die stappen misgaan of niet.

[ Voor 5% gewijzigd door Hydra op 01-10-2012 14:23 ]

[Torrentus]

Late reactie, maar vind het toch nodig om dit topic nog even netjes 'af te sluiten'. Bedankt allen voor jullie hulp, het probleem was uiteraard al snel opgelost met de eerste reacties, maar zoals eerder al gezegd bijzonder om te zien wat voor een discussie dit simpele stukje code kan uitlokken..

Zoals Silentuz al aangaf is het inderdaad een stukje code uit de prakticum lessen TI op de uTwente, om jullie direct gerust te stellen; van een tweede-weeks-student.

Heb met interesse de hele discussie gelezen, en er (natuurlijk) van geleerd. Bedankt allen!