Luku 3.5: Limsaa, jalkapalloa ja virheitä

Limuautomaatin tila ja sen alustaminen

Katsotaan ensiksi luontiparametreja ja ilmentymämuuttujia:

class VendingMachine(var bottlePrice: Int, private var bottleCount: Int):
  private var earnedCash = 0
  private var insertedCash = 0

Helppoja limumetoditoteutuksia

Viisi metodeista ovat toteutukseltaan varsin suoraviivaisia aiempien lukujen perusteella.

def addBottles(newBottles: Int) =
  this.bottleCount = this.bottleCount + newBottles

def insertMoney(amount: Int) =
  this.insertedCash = this.insertedCash + amount

def isSoldOut = this.bottleCount == 0

def enoughMoneyInserted = this.insertedCash >= this.bottlePrice

def emptyCashbox() =
  val got = this.earnedCash
  this.earnedCash = 0
  got

Ehkä on hyvä katsoa samaa koodia uudestaan palauttaen mieleen Scalan tyylikäytäntöjä:

def addBottles(newBottles: Int) =
  this.bottleCount = this.bottleCount + newBottles

def insertMoney(amount: Int) =
  this.insertedCash = this.insertedCash + amount

def isSoldOut = this.bottleCount == 0

def enoughMoneyInserted = this.insertedCash >= this.bottlePrice

def emptyCashbox() =
  val got = this.earnedCash
  this.earnedCash = 0
  got

Mainittuja käytäntöjä voit kerrata esim. kurssin tyylioppaasta.

toString-metodin toteutus

toString-metodissa pääsemme hyödyntämään if–else-lauseketta. Tässä yksi toteutustapa:

override def toString =
  "earned " + this.earnedCash / 100.0 + " euros, " +
    "inserted " + this.insertedCash + " cents, " +
    (if this.isSoldOut then "SOLD OUT" else s"$bottleCount bottles left")

override def toString =
  val earnings = this.earnedCash / 100.0
  val bottleStatus = if this.isSoldOut then "SOLD OUT" else s"$bottleCount bottles left"
  s"earned $earnings euros, inserted $insertedCash cents, $bottleStatus"

sellBottle-metodin toteutus

Tässä eräs toimiva toteutustapa sellBottle-metodille, jonka tehtävänä on "myydä pullo" eli muuttaa automaatin raha- ja pullotietoja sekä palauttaa joko vaihtorahan määrä tai negatiivinen luku myynnin epäonnistumisen merkiksi.

def sellBottle() =
  if this.isSoldOut then
    -1
  else if !this.enoughMoneyInserted then
    -1
  else
    this.earnedCash = this.earnedCash + this.bottlePrice
    this.bottleCount = this.bottleCount - 1
    val changeGiven = this.insertedCash - this.bottlePrice
    this.insertedCash = 0
    changeGiven

Limuautomaattitoteutuksen laadusta

Tuo sellBottle-toteutus kyllä toimii spesifikaation mukaisesti. Mutta se saattaa sinustakin näyttää peräkkäisine if-käskyineen aavistuksen verran ikävältä. Koodi ei myöskään ole aivan "DRY" eli toisteeton (luku 1.4), koska siinä toistuu sama kohta — -1:n palauttaminen — turhaan kahdesti.

Lisäksi voimme kyseenalaistaa, onko hyvä ajatus palauttaa negatiivinen luku merkkinä siitä, ettei pulloa saatu myytyä — vaikka negatiivisen luvun käyttö epäonnistumisen merkkinä perinteinen ohjelmointikikka onkin. Tämä nimittäin avaa mahdollisuuden huolimattomuusvirheelle, jossa metodin kutsuja ei muista tarkistaa arvon etumerkkiä ja käsittelee palautettua negatiivista lukua kuin se olisi saadun vaihtorahan määrä ja osto olisi onnistunut.

Tulet oppimaan kurssilla tekniikoita, joilla sellBottle-metodia voi parantaa. Voit pitää tämän metodin ja nämä laatukysymykset mielessä lukiessasi myöhempiä lukuja.

Muuttujat Scaladoc-pohjaisissa tehtävissä

Kuten luku 3.2 kertoi, yksityiset muuttujat eivät kuulu luokan julkiseen rajapintaan eivätkä siksi tule mukaan Scaladoc-dokumentteihin, joiden tehtävä on kuvata luokan käyttötapaa luokan ulkopuolelta katsottuna.

Niissä kurssin tehtävissä, joissa annetaan Scaladoc-muotoinen spesifikaatio, tämä tarkoittaa käytännössä sitä, että dokumenteissa näkyvät ilmentymämuuttujat sinunkin tulee määritellä julkisiksi laatimaasi ohjelmakoodiin (kuten bottlePrice äsken). Toisaalta muita julkisia ilmentymämuuttujia kuin dokumentaation määräämät ei luokalla tulisi olla.

Ei ole epätavallista, että tarvitset luokan sisäiseen tilakirjanpitoon muita muuttujia kuin scaladocin kuvaamat julkiset muuttujat, mutta tee noista lisämuuttujista yksityisiä (kuten esim. bottleCount- ja earnedCash-muuttujista äsken).

Huomaa lisäksi, että julkisen ilmentymämuuttujan vaihtaminen valista variksi tarkoittaa, että tuohon muuttujaan voi sijoittaa arvon luokan ulkopuolelta. Sekin siis muuttaa julkista rajapintaa. Jos dokumentaatio pyytää valin, tee val. Yksityisiin muuttujiin voit valita val´in tai `varin, mutta val on yleensä parempi vaihtoehto (luku 1.4).

Pikkutehtävä

val machine = VendingMachine(250, 10)machine: o1.soda.VendingMachine = earned 0.0 euros, inserted 0 cents, 10 bottles left
machine.earnedCash = 123456-- Error:
  |machine.earnedCash = 123456
  |^^^^^^^^^^^^^^^^^^
  |variable earnedCash cannot be accessed

val accessToCurrentValue = machine.getClass.getDeclaredField("earnedCash")accessToCurrentValue: java.lang.reflect.Field = private int o1.soda.VendingMachine.earnedCash
accessToCurrentValue.setAccessible(true)accessToCurrentValue.set(machine, 123456)machine.emptyCashbox()res0: Int = 123456

Tehtävänanto

Tutustu moduulin Scaladoc-dokumentaatioon sekä ohjelmakoodiin. (Kertaus: löydät dokumentaation IntelliJ’stä moduulin doc-kansiosta sekä selaimella luvun alun linkistä. Tarkemmat ohjeet luvussa 3.2.)

Koodia tutkiessa osoittautuu, että:

• Siinä on syntaksivirheitä ("kielioppivirheitä"; ks. luku 1.8), jotka estävät luokkien käytön tyystin.

• Osa dokumentaation kuvaamista metodeista puuttuu. Eikä siinäkään vielä kaikki:

• Koodissa on toiminnallisia bugeja. Osa Match-luokan metodeista on kieliopillisesti oikein muttei toimi niin kuin dokumentaatio kuvaa.

Tehtäväsi on:

• korjata virheet luokista Match ja Club niin, että luokat vastaavat annettua spesifikaatiota

• täydentää puuttuvat metodit mainittuihin luokkiin

• korjata testClubAndMatch-testiohjelma toimivaksi eli sellaiseksi, että se käyttää Match-luokkaa ohjelmassa olevien kommenttien mukaisesti

• täydentää tätä testiohjelmaa niin, että se testaa luokkia kattavammin (parhaaksi katsomallasi tavalla)

• varmistaa testiohjelman avulla, että kaikki pelaa.

Ohjeita ja vinkkejä

Virheiksi on valittu sellaisia, joita ohjelmoinnin opiskelijat joskus tekevät. Käy ne läpi ajatuksella, jotta osaat välttää tai ainakin korjata vastaavat tulevissa tehtävissä, joissa kirjoitat enemmän omaa koodia.

Alla on vaiheittainen opastus tehtävään.

Luithan varmasti Scaladoc-dokumentaation ensin? Silmäilitkö myös annettua koodia?

Vaihe 1/16: Club-luokan ensimmäinen virhe

Paina Football1-moduulin tai jonkin sen tiedostoista ollessa valittuna F10 (tai valikosta Build → Build Module 'Football1'). IntelliJ’n Build-välilehti ponnahtaa esiin. Siellä näkyy luettelot virheilmoituksista, joista osa liittyy Clubiin, osa Matchiin ja osa testiohjelma testClubAndMatchiin.

Aloitetaan Club-luokasta. IntelliJ’n mukaan kaksi kolmesta virheestä on class-alkuisella rivillä ja kolmas tiedoston lopussa end-rivillä.

class-rivillä on tosiaan virhe, ja se toistuu kahdesti samalla rivillä. IntelliJ’n virheilmoitus ':' expected but ',' found antaa osviittaa. Sen voi vapaasti suomentaa ”Tähän piti tulla kaksoispiste, mutta vastaan tulikin (jo) pilkku.”

Voit napsauttaa ensimmäistä virheilmoitusta kahdesti, niin editoriin tulee esiin juuri se rivi, johon virheilmoitus viittaa. Kokeile!

Rivillä punainen korostus osoittaa luontiparametrien val name, val stadium välistä pilkkua.

Miksi tuossa pitäisi olla kaksoispiste? Mitä muuta siitä vielä puuttuu? Ehkä huomasit sen jo itsekin. Jos et, vertaa tätä määrittelyä aiempin esimerkkien luokkamäärittelyihin. Korjaa virhe nyt, niin jatketaan. Niin, ja korjaa se toinenkin vastaava virhe samalla rivillä.

Korjauksen kirjoitettuasi käännä ("rakenna"; build) koodi uudestaan: F10.

Vaihe 2/16: Club-luokan toinen virhe

Toinen Club-virheilmoitus osoittaa luokan loppua. Tuon viimeisen rivin virhe on edellistäkin pienempi.

Virheilmoitus kertoo: misaligned end marker. Loppumerkki on väärin asemoitu. Korjaa sisennys. (Koska loppumerkki on vapaaehtoinen, sen voisi myös poistaa.)

Toistaiseksi kohtaamamme virheilmoitukset ovat olleet kohtalaisen selkeitä ja osoittaneet juuri niille riveille, joissa virheet ovat. Näin ei ole aina. Monesti virheilmoitukset ovat epäselvempiä, ja niitä voi joutua pohtimaan pidempään tai selvittelemään vaikkapa googlitse. Harjoitus tekee mestarin.

Vaihe 3/16: Match-luokka: varoituksia ja virheilmoituksia

Tutkitaan seuraavaksi ensimmäistä varoitusta, jonka IntelliJ antaa Match-luokasta: Line is indented too far to the right, or a `{` or `:` is missing. Tuplaklikkaa varoitusta, niin näet, että se osoittaa riviin, jolla lukee private var homeCount.

Huoli on aiheellinen, mutta varsinainen ongelma on eri rivillä.

Varoitusilmoitus ehdottaa, että kyseessä saattaisi olla puuttuva välimerkki, ja sellainen tosiaan puuttuu pari riviä ylempää class-alkuiselta riviltä. Lisää se rivin loppuun. Käännä koodi uudestaan F10llä. Luettelo Match-luokan ongelmista päivittyy.

Varoituksen juurisyy oli siis puuttuva kaksoispiste, jonka vuoksi tietokone ei tulkinnut homeCount-muuttujan määrittelyn — eikä sitä alempienkaan rivien — olevan osa Match-luokkaa. Se tulkitsi ne Match-luokasta erillisiksi määrittelyiksi, jotka oli kuitenkin sisennetty kuin ne olisivat Match-luokan sisältöä, mikä haiskahti ohjelmointivirheeltä.

Vaihe 4/16: Match-luokka: lisää varoituksia

Match-luokasta — tarkemmin sanoen isGoalless-metodista — varoitellaan muutakin. Varoitus sanailee, että discarded non-Unit value of type Boolean ja ehdottaa vielä, että ehkäpä siihen kohtaan kuuluisi kirjoittaa Unit.

Tällekin varoitukselle on aihetta, sillä tuossa metodissa on jotain pielessä. Ilmoitus on kuitenkin harhaanjohtava ja ehdotus Unitin lisäämisestä huono.

Kenties jo näetkin, mikä on vikana. Tehdään silti niin, ettei vielä korjata tuota metodia, sillä on sivistävää tutkia, millaisia oireita tuo virhe aiheuttaa muualla ohjelmassa. Palaamme siihen myöhemmin. Anna nyt noiden varoitusten olla ja jatka seuraavaan vaiheeseen.

Vaihe 5/16: goalDifference

Match-luokasta tulee virhe missing return type, jonka tuplaklikkaaminen vie goalDifference-metodin kohdalle.

Virheilmoitus puuttuvasta paluuarvon tyypistä on teknisesti oikein muttei kerro selvästi, mikä varsinainen ohjelmointivirhe on tehty.

Vie hiiren kursori goalDifference-nimen päälle, niin IntelliJ näyttää lisätietoja metodista. Siellä näkyy muun muassa, että metodin paluuarvon tyyppi olisi Unit. Scala ei ole siihen Unitia parempaakaan tyyppiä saanut pääteltyä, koska metodin määrittelyssä on virhe.

Funktion rungossa olisi tarkoitus olla lauseke, joka määrää funktion paluuarvon. Tästä funktiomäärittelystä kuitenkin puuttuu välimerkki, minkä vuoksi funktion runko ei tule määritellyksi lainkaan.

Emme halua metodin palauttavan Unit vaan Int. Korjaukseksi riittää yhtäsuuruusmerkin lisäys, jolloin metodi palauttaa runkona olevan lausekkeen arvon. (Jos haluat, voit myös muuttaa koko metodin yksiriviseksi.)

Vaihe 6/16: isHigherScoringThan

Käännä koodi painamalla F10. Ongelmaluettelo päivittyy.

Match-luokan kohdalla näkyy vielä yksi virheilmoitus punaisella ja ne pari varoitusta keltaisella. Tutkitaan viimeistä virheilmoitusta. (testClubAndMatch hälyttää myös, ja kovasti hälyttääkin, mutta katsotaan sitä kohta.)

IntelliJ’n mukaan koodi this.totalGoals(anotherMatch) on viallinen, ja IntelliJ on tässä ihan oikeassa. Huomaatko miksi? Virheilmoitus method totalGoals in class Match does not take parameters on osuva.

Korjaa virhe ja toinen vastaava samalta riviltä. Käännä koodi uudestaan. Nyt näyttää siltä, että Match olisi varoitusviestejä lukuunottamatta kunnossa. Älä kuitenkaan vielä huokaise helpotuksesta.

Vaihe 7/16: Kaikki pielessä testiohjelmassa

Käynnistysfunktion testClubAndMatch koodista tulee virheitä solkenaan. Suurin osa niistä on muotoa illegal start of toplevel definition, jollainen näkyy tulevan yhdestä jos toisestakin tuon funktion println- ja if-rivistä.

Virheilmoitukset eivät ole selkeimmästä päästä mutta antavat vihjeen siitä, miten tietokone on koodin jäsentänyt.

Nämä ilmoitukset voi lukea ”koodirivi, joka on uloimmalla tasolla, ei voi alkaa noin”. Tässä ”uloin taso” tarkoittaa sellaista koodia, joka ei ole minkään funktion, yksittäisolion tai luokan sisällä.

Tokihan noiden virherivien pitäisi olla käynnistysfunktion testClubAndMatch sisällä. Miksi IntelliJ sitten väittää, että tuo koodi olisi sen sijaan ”uloimmalla tasolla” ja siksi epäkelpoa?

Syy löytyy katsomalla ensimmäisiä rivejä, joilta tuo virhe tulee. Tarkka silmäys kertoo, että tuo println-rivi on sisennetty väärin, kuten on seuraavakin. Ne tosiaan ovat ”uloimmalla tasolla”, jonne ne eivät kuulu. Virhesisennys ikään kuin katkaisee käynnistysfunktion määrittelyn ja aiheuttaa siten alempienkin rivien vastaavat virheilmoitukset, vaikka ne rivit onkin sisennetty oikein.

Korjaa. Paina tämänkin tehtyäsi F10 ja muista sama myös edetessäsi seuraaviin vaiheisiin.

Vaihe 8/16: Otteluiden luominen

Yksi valituksista kohdistuu käskyyn Match(club2, club1) testiohjelmassa testClubAndMatch.

Mutta sehän näyttää olevan aivan kunnossa. Se on aivan kunnossa.

Tämä on hyvä esimerkki siitä, ettei virheilmoitus aina osoita lainkaan siihen paikkaan, jossa varsinainen virhe on. Virheilmoitus osoittaa nyt testiohjelman ohjelmakoodiin ja ilmoittaa, ettei se toimi. Ja eihän se toimikaan, mutta syy on siinä, että Match-luokka on määritelty virheellisesti ja testiohjelma yrittää käyttää sitä tavalla, jolla käytön pitäisi onnistua.

Huomaa, että virheilmoitus on monirivinen ja näkyy kokonaisuudessaan Build-välilehdellä virheluettelon vieressä, kun valitset kyseisen virheen luettelosta.

Tämä on ns. type mismatch -virhe. Tällainen virhe sanoo, että tiettyyn kohtaan koodia kaivattiin erästä tyyppiä oleva arvo, mutta löytyikin jotain muuta. Tällaisista virheilmoituksista on melko usein helppo päätellä, missä virhe on; tässäkin tapauksessa virheilmoitus kertoo kohtalaisen selvästi, mistä on kyse. Lue se ja vertaa keskenään virheilmoituksen osoittamaa riviä, Match-luokan Scaladoc-dokumentaatiota ja annettua Match-toteutusta.

Korjaa virhe.

Vaihe 9/16: addHomeGoal

Tarkastellaan seuraavaksi virheilmoituksia, jotka kertovat, että value addHomeGoal is not a member of o1.football1.Match. Siis "Mitään addHomeGoalia ei löydy Match-luokasta."

Häh? Onhan siellä koodissa tuo metodi. Katso vaikka itse.

Katsoitko tarkkaan? Ja huomasitko virheilmoituksen kysymyksen: did you mean AddHomeGoal?

Tämänlaisen virheilmoituksen saadessasi tarkista aina oikeinkirjoitus. Kirjoitusvirhe voi olla kutsuvassa koodissa tai kutsutussa koodissa. Huomaa myös, että virheilmoitusten did you mean -ehdotukset eivät välttämättä ole oikeassa. Toteuta ohjelma spesifikaation (eli tässä Scaladocin) mukaiseksi.

Vaihe 10/16: homeCount ja awayCount

Sitten: variable awayCount in class Match cannot be accessed ja sama homeCount-muuttujalle.

Olemme onnekkaita, sillä ilmoitus kertoo sekä virheen todellisen sijainnin että syyn. Se sanoo, ettei mainittuihin Match-olion muuttujiin pääse käsiksi testClubAndMatch-ohjelmasta.

Jos et jo aiemmin huomannut, miten Match-luokassa on sekä muuttujat homeCount ja awayCount että metodit homeGoals ja awayGoals, niin kiinnitä siihen huomiota nyt. Millaisesta virheestä on kyse? Onko virhe Matchin vai testiohjelman koodissa?

Korjaa virhe.

Vaihe 11/16: isHomeWin ja isAwayWin

Jaaha: value isHomeWin is not a member of o1.football1.Match ja sama isAwayWinille.

Mutta ihan varmastihan Match-luokassa on nyt nuo* metodit! Nimetkin on oikein kirjoitettu.

Match-luokan koodista nuo määrittelyt toisiaan löytyvät, mutta pienen virheen vuoksi noita metodeita ei kuitenkaan nyt ole Match-olioilla tarjolla. Seuraava pikkuesimerkki johdattaa virheen äärelle.

Sanotaan, että haluamme määritellä kolmimetodisen luokan:

class Luokka:

  def toiminto1(luku: Int) =
    println(luku)

  def toiminto2 = 1 + 1

  def toiminto3 = 2 + 2

end Luokka

Ehkä kuitenkin vahingossa kirjoitamme sen näin:

class Luokka:

  def toiminto1(luku: Int) =
    println(luku)

    def toiminto2 = 1 + 1

    def toiminto3 = 2 + 2

end Luokka

class Luokka:

  def toiminto1(luku: Int) =
    println(luku)

    def toiminto2 = 1 + 1

    def toiminto3 = 2 + 2
  end toiminto1

end Luokka

Nyt siis toiminto2 ja toiminto3 ovatkin sisennysten vuoksi toiminto1-metodin sisällä. Niistä tulee ensimmäisen metodin paikallisia funktioita eikä luokan metodeita. (Tämä ei ollut lainkaan tarkoituksemme, mutta paikallisilla funktioilla on kyllä paljonkin muuta käyttöä, mistä kerrotaan kurssilla myöhemmin.)

Korjaa metodit isHomeWin ja isAwayWin Match-luokasta. Tarkkana sisennyksissä!

Vaihe 12/16: totalGoals

Yksi virheistä liittyy match1.totalGoals()-metodikutsuun. Ilmoitus on tutunlainen (hieman ylempää): method totalGoals does not take parameters. Samoin sen syy on tuttu, vaikka tässä testClubAndMatch ei tarjoa metodille varsinaisia parametreja vaan vain tyhjän parametriluettelon.

Korjaa.

Vaihe 13/16: isGoalless kuntoon

Virhe: Found: Unit   Required: Boolean. Tämä type mismatch -virhe osoittaa isGoalless-kutsuihin testiohjelmassa.

Selvästikin if-käskyyn tarvitaan Boolean-tyyppinen lauseke. Jostain syystä isGoalless ei näytä sellaista tuottavan, vaan saamme Unitin.

Pystytkö selvittämään tai arvaamaan, mikä isGoalless-metodissa on vikana? Saatko ongelman korjattua? Saatko toteutuksesta hyvin yksinkertaisen? Joskus korjaaminen tarkoittaa vain koodin poistamista.

Jos ongelman ymmärtäminen ei meinaa onnistua, katso alempaa Lisää virhetilanteita: arvojen palauttaminen ja valintakäsky. Tuo kappale käsittelee juuri tällaisia virheitä. Tee se pikkutehtäväkin. (Ja muista vielä vinkki: isGoallessille voi määritellä erittäin yksinkertaisen, toimivan toteutuksen.)

Kun korjaat tämän virheen, poistuvat myös aiemmin huomaamamme varoitusviestit.

Vaihe 14/16: location

Viimeiset käännösaikaiset virheet oliosta testClubAndMatch johtuvat jälleen siitä, että Match-luokka on vajavainen.

Ilmoitus value location is not a member of o1.football1.Match kertoo tässä, että location-metodi on jäänyt Match-luokasta määrittelemättä. Ilmoitus on samanlainen kuin joistakin muistakin metodeista yllä, mutta syy on nyt erilainen: location-metodi tosiaan puuttuu kokonaan.

Kirjoita toteutus location-metodille.

Vaihe 15/16: Testaa

Ohjelman pitäisi nyt olla ajokunnossa. Aja testClubAndMatch. Mieti, mitä sen pitäisi tulostaa ja mitä se todellisuudessa tulostaa.

Huomaat, että osa tulosteista on kunnossa, mutta kaikki ei ole hyvin. Match-luokka toimii edelleen osin dokumentaation vastaisesti, vaikka IntelliJ ei luokasta enää virheitä löydäkään.

Alla on vinkkejä puutteiden korjaamiseksi.

Vaihe 16/16: Korjaa ja täydennä

Korjaa Match-luokkaan jääneet puutteet: yksi virheellinen metodi ja puuttuva toString.

Ohjeita ja vinkkejä:

• Muokkaa testClubAndMatch-ohjelmaa parhaaksi katsomallasi tavalla virhettä etsiessäsi.

• Jos toString-metodin toteuttaminen Match-luokkaan tuottaa vaikeuksia:

  1. Varmista, että luit metodin koko Scaladocin. Haluttu toiminta on kuvattu siellä esimerkkien kanssa.

  2. Varmista, että käytit override-sanaa alussa.

  3. Katso VendingMachine-luokan toString-metodi, josta on parikin eri toteutusta yllä.

  4. Lue jo tässä välissä loput tästä luvusta. Kyse voi olla jostakin alempana esitellystä if-käskyihin liittyvästä virhetilanteesta.

  5. Pyydä apua, jos nuo vinkit eivät auttaneet.

Miksei tämä toimi?

Sanotaan, että haluamme laatia funktion, joka palauttaa parametriksi saamansa kokonaisluvun neliön, jos annettu luku on positiivinen. Negatiivisen parametriarvon tapauksessa neliön sijaan palautetaankin nolla. Funktion parametrin tyyppi olisi Int ja paluuarvon samaten.

Seuraava toteutus on aloittelijalle varsin tyypillinen. Siinä on selkeästi ilmaistu molemmat tapaukset erillisillä if-käskyillä:

def kokeilu(luku: Int) =
  if luku > 0 then luku * luku
  if luku <= 0 then 0

Onko tässä sitten jotain vikaa? Kokeillaan REPL:issä:

def kokeilu(luku: Int) =
  if luku > 0 then luku * luku
  if luku <= 0 then 0def kokeilu(luku: Int): Unit
-- Potential Issue Warning:
    if luku <= 0 then 0
...

Tutkitaan vielä. Kun koetamme kutsua funktiota, ei käy hyvin:

kokeilu(10)7 + kokeilu(10)-- Type Error:
7 + kokeilu(10)
^^^
None of the overloaded alternatives of method + in class Int ... match arguments (Unit)

Emme saa paluuarvona lukua. Ja kun yritämme käyttää funktiota osana laskutoimitusta, saamme virheilmoituksen, jonka voi suomentaa suunnilleen "plus-operaattoria ei ole määritelty yhdistelmälle Int + Unit". Selvästi funktiomme palauttaa vain Unit. Mistä on kyse?

Ongelman selitys

Katsotaan koodiamme tarkasti ja muistaen, että paluuarvo on viimeiseksi evaluoitavan lausekkeen arvo.

def kokeilu(luku: Int) =
  if luku > 0 then luku * luku
  if luku <= 0 then 0

Koska näin (huonosti) määritellyn funktion paluuarvo voi tilanteesta riippuen olla joko Int tai tarkemmin määrittelemätön, Scala-työkalusto päätyy tulokseen, että koko lausekkeen (eli funktion toisen rivin) tyyppi on vain Unit eli "ei oikein mitään".

if luku <= 0 then
  0
  ()
else
  ()

Toimiva versio

No, miten se sitten saadaan toimimaan?

def kokeilu(luku: Int) =
  if luku > 0 then luku * luku else 0

Entä tämä ratkaisu?

def kokeilu(luku: Int) =
  if luku > 0 then luku * luku else if luku <= 0 then 0

Pari käytännön vinkkiä virheenetsintään

Jos saat hämmentäviä virheilmoituksia, katso tarkasti, mitkä ovat kunkin lausekkeen ja paluuarvon tietotyypit. Tämä kannattaa usein muutenkin mutta erityisesti silloin, jos ilmoituksessa näkyy sana Any tai Unit ja olet käyttänyt if-valintakäskyä.

Lisäkikka: ohjelmointityökalut osaavat joissakin tapauksissa antaa selkeämpiä virheilmoituksia, jos kirjaat funktiollesi paluuarvojen tyypin erikseen (luvun 1.8 mukaisesti):

def kokeilu(luku: Int): Int = // jne.

Tyypin saa kirjata näin vaikka kaikille funktioille. Paluuarvojen vapaaehtoinen kirjaaminen voi muutenkin selkiyttää ohjelmia ja vähentää virheitä. Monet Scala-ohjelmoijat merkitsevät paluuarvon tyypin kaikkiin julkisiin metodeihin (mitä sinun kuitenkaan ei ole pakko O1:ssä tehdä).