ProgrammeringsBaren! Småprat, om det du elsker!

[GeirGrusom]

Litt av greia med å ha den til slutt er vel nettopp det å sikre at en verdi blir sendt tilbake til funksjonskallet?

Hvorfor skal det være et poeng? Feil verdi er mye verre enn at programmet ikke kompilerer i det hele tatt.

Du må ha tenkt på alle mulige kombinasjoner av input, så hvorfor ikke sørge for at det faktisk skjer?

[Kanutus]

Om feil verdi er mye verre enn at programmet ikke kompilerer må vel være opp til enhver. Å sjekke for 'alle mulige kombinasjoner av input' er selvfølgelig en viktig del av programmet, men du har jo heller ikke sagt noe om hvor disse inputene kommer fra, og hvorfor akkurat det skulle være et problem. Akkurat nå har du foreslått to ting, én løsning som ikke kompilerer, og én som gjør det, da er det ikke vanskelig å si hvem av dem som er best ...

[Capitalist Hippie]

Om feil verdi er mye verre enn at programmet ikke kompilerer må vel være opp til enhver. Å sjekke for 'alle mulige kombinasjoner av input' er selvfølgelig en viktig del av programmet, men du har jo heller ikke sagt noe om hvor disse inputene kommer fra, og hvorfor akkurat det skulle være et problem. Akkurat nå har du foreslått to ting, én løsning som ikke kompilerer, og én som gjør det, da er det ikke vanskelig å si hvem av dem som er best ...

 

Den som ikke kompilerer er så klart best; d.v.s. at kompilator plukker opp feil input ved kompileringstid; d.v.s. så tidlig som mulig slik at det er lett å finne (og/eller trigge) feilen.

 

Samtidig må en sikre seg m.t.p. kjøretid; jeg ville hatt en else (ikke else if) som throw'et. Eventuelt en throw etter hele if/else blokka.

Endret 1. oktober 2012 av nostdal.org

[Kanutus]

Jeg skjønner ikke helt problemet. Hva er uting med å ha retur på slutten av funksjonen? Litt av greia med å ha den til slutt er vel nettopp det å sikre at en verdi blir sendt tilbake til funksjonskallet? Du kan jo også la vær å ha return i hver av if-else-ene og kun gi en returnvariabel en gitt verdi, så kan du heller sende tilbake en -1 dersom du vil ha en feilsjekk. Det blir litt ryddigere etter min mening, og feil er det i allefall ikke.

Jeg liker å bruke return i if-setningene da jeg da kan være rimelig sikker på at bugs lengre nede ikke påvirker returverdien.

 

Det er kanskje ikke noe fasitsvar på akkurat den der, men at man velger det som passer best for situasjonen , eller?

[Kanutus]

Om feil verdi er mye verre enn at programmet ikke kompilerer må vel være opp til enhver. Å sjekke for 'alle mulige kombinasjoner av input' er selvfølgelig en viktig del av programmet, men du har jo heller ikke sagt noe om hvor disse inputene kommer fra, og hvorfor akkurat det skulle være et problem. Akkurat nå har du foreslått to ting, én løsning som ikke kompilerer, og én som gjør det, da er det ikke vanskelig å si hvem av dem som er best ...

 

Den som ikke kompilerer er så klart best om kompilator plukker opp feil input ved kompileringstid; d.v.s. så tidlig som mulig slik at det er lett å finne (og trigge) feilen.

 

Samtidig må en sikre seg m.t.p. kjøretid; jeg ville hatt en else (ikke else if) som throw'et.

 

Kompilatoren vil vel bare plukke opp den feilen som du bevisst har lagt til her, i dette tilfellet, og det vil vel ikke hjelpe i det hele tatt? Vi snakker jo om forskjell på logic error, runtime error og syntax error også, ikke sant? Eller er jeg helt på jordet her nå?

[tomsi42]

Det er kanskje ikke noe fasitsvar på akkurat den der, men at man velger det som passer best for situasjonen , eller?

Skal ikke protestere på det.

 

Kompilatoren vil vel bare plukke opp den feilen som du bevisst har lagt til her, i dette tilfellet, og det vil vel ikke hjelpe i det hele tatt? Vi snakker jo om forskjell på logic error, runtime error og syntax error også, ikke sant? Eller er jeg helt på jordet her nå?

Noen kompilatorer kan fange opp manglende valg i if-setninger, såvidt jeg har skjønt. Slik at det å ikke ha en return på slutten av funksjonen er helt greit. Men om den er smart nok til å fange opp dette i litt mer avanserte problemstillinger er jeg usikker på.

[GeirGrusom]

Det var en veldig forenkling av et praktisk problem jeg støtte borti av gammel kode hvor logikken ikke var komplett.

Det var ikke jeg som hadde skrevet koden, men veldig forenklet så var 'a' om en nøkkel fantes i en dictionary, og 'b' om en tidligere operasjon hadde fullført. Logikken manglet fullstendig om 'a' var sann, og om b var true eller false, som førte til at koden sjekket opp dictionary nøkkelen selv om koden allerede visste at nøkkelen ikke fantes, men koden gikk lenger enn den skulle gjort.

Endret 1. oktober 2012 av GeirGrusom

[Kanutus]

Det var en veldig forenkling av et praktisk problem jeg støtte borti av gammel kode hvor logikken ikke var komplett.

Det var ikke jeg som hadde skrevet koden, men veldig forenklet så var 'a' om en nøkkel fantes i en dictionary, og 'b' om en tidligere operasjon hadde fullført. Logikken manglet fullstendig om 'a' var sann, og om b var true eller false, som førte til at koden sjekket opp dictionary nøkkelen selv om koden allerede visste at nøkkelen ikke fantes, men koden gikk lenger enn den skulle gjort.

 

Skjønner! Likevel så skjønner jeg fortsatt ikke helt hvor du vil hen. Du har en kodesnutt som inneholder to booleans (og ikke en uendelighet av inputs). Det kan maks gi fire forskjellige alternativer. Om du sjekker for disse fire, og utfører videre kode basert på det, kan det da ikke være logikken det er noe galt med, men resten av koden, ikke sant? Om du da har en return i bånn for å tilfredsstille en kompilator eller ikke skulle da ikke spille noen rolle. Eller ...?

[tomsi42]

Etter å ha tenkt meg om litt, så tror jeg at GeirGrusom muligens stilte spørsmålet helt åpent i utgangspunktet. Pga. litt tankevirksom etter han fant denne buggen.

 

Jeg vet ikke hvor ofte man er oppe i en situasjon der man har maks fire utganger. Som oftest er det vel fler, og da vanskelig å ta høyde for alle casene?

 

Så da kan muligens spørsmålet kokes ned til at skal man ha en default verdi som returner når ingen av casene treffer, eller spesifikt returne en fornufitg verdi for de casene man har kontroll på, og kaste en exception hvis de ikke tilfredstilles. For det er vel egentlig det som er problemet med kodesnutten til GeirGrusom. Den prøver liksom begge deler.

Endret 1. oktober 2012 av tomsi42

[Kanutus]

Etter å ha tenkt meg om litt, så tror jeg at GeirGrusom muligens stilte spørsmålet helt åpent i utgangspunktet. Pga. litt tankevirksom etter han fant denne buggen.

 

Jeg vet ikke hvor ofte man er oppe i en situasjon der man har maks fire utganger. Som oftest er det vel fler, og da vanskelig å ta høyde for alle casene?

 

Så da kan muligens spørsmålet kokes ned til at skal man ha en default verdi som returner når ingen av casene treffer, eller spesifikt returne en fornufitg verdi for de casene man har kontroll på, og kaste en exception hvis de ikke tilfredstilles. For det er vel egentlig det som er problemet med kodesnutten til GeirGrusom. Den prøver liksom begge deler.

 

Da er jeg litt mere med, og forstår problemstillingen bedre. Blir koden for komplisert stiller det nok mere krav til utvikleren enn det jeg er kar om. Jeg mener likevel at mye av kunsten med å programmere er å lage kode som andre kan lese og forstå, og at det skal være så enkelt som mulig, men ikke enklere ... I dette tilfellet gjelder det da kanskje å dele opp koden i mindre biter, f.eks. ved å sjekke validitet først, og så sjekke logikken etterpå. Kunne være morsom å se et mere konkret, ikke så forenklet eksempel, og se hva vi syntes om det da ... : )

[GeirGrusom]

Det er et nisjeproblem. Det skjer nesten aldri, men den ene måten å skrive på vil effektivt føre til at det aldri kan skje. I tillegg så vil det også i eksempelet føre til færre muteringer av state, som også nødvendigvis er en bra ting.

[vebbiii]

Har noen av dere opplevd før at programmet deres bare har sluttet å kjøre på et visst punkt i koden, uten noen form for feilmelding eller exception?

[tomsi42]

Har noen av dere opplevd før at programmet deres bare har sluttet å kjøre på et visst punkt i koden, uten noen form for feilmelding eller exception?

Bare dødd stille og rolig mener du?

 

Ja. Og i de fleste språk

[vebbiii]

Har noen av dere opplevd før at programmet deres bare har sluttet å kjøre på et visst punkt i koden, uten noen form for feilmelding eller exception?

Bare dødd stille og rolig mener du?

 

Ja. Og i de fleste språk

 

Synes det hvertfall kan skrike litt før det dør da Var første gangen jeg opplevde det i går. Satt å klødde meg i hodet i noen timer for å si det sånn.

[Matsemann]

Flere ganger her også. Hva var problemet ditt?

 

Her er det som regel en case jeg ikke har tenkt på som gir en feil flyt men en "lovlig" tilstand. Spesielt vanlig i PHP om en ikke kjører med notices aktivert.

[vebbiii]

Problemet var at jeg prøvde å skrive ut cursor.getString(0) fra SQL forespørslen før jeg brukte cursor.moveToFirst(), altså en iterator som gikk gjennom hver rad i tabellen. Greit nok det, tullete feil av meg, men fortsatt irriterende å ikke få feilmelding

[GeirGrusom]

Jeg kan ikke telle hvor mange ganger jeg har opplevd at et program funker helt glimrende i Debug, men kompilerer man til release, så bare feiler det uten å gi noen feilmelding. Det er alltid en programmeringsfeil, men vanskelig å finne ut av fordi release og debug alltid vil være forskjellige miljøer., og i Release har man ikke like mye informasjon for å debugge.

[mushin]

Skulle gjerne hatt tak på en av disse pakkene her:

http://www.iro.umontreal.ca/~simardr/ssj/doc/html/umontreal/iro/lecuyer/functionfit/package-summary.html

Ligger de her? Eller er det kun info her?

[GeirGrusom]

Skulle gjerne hatt tak på en av disse pakkene her: http://www.iro.umontreal.ca/~simardr/ssj/doc/html/umontreal/iro/lecuyer/functionfit/package-summary.html Ligger de her? Eller er det kun info her?

 

http://www.iro.umontreal.ca/~simardr/ssj/indexe.html

[mushin]

Skulle gjerne hatt tak på en av disse pakkene her: http://www.iro.umont...ge-summary.html Ligger de her? Eller er det kun info her?

 

http://www.iro.umont...ssj/indexe.html

 

Mange takk!