Som ett exempel, så kanske du som Java-programmerare någon gång har försökt refaktorisera bort lite duplicerad kod som använder antingen en StringBuilder eller StringBuffer. Då har du kanske försökt leta fram en gemensam bastyp att försöka applicera lite polymorfism på, och har då hittat interfacet metoden Appendable med metoden append. Då tvingas du att hantera ett checked exception IOException med Java.
Med Scala blir du däremot inte tvingad att propagera exceptions i metodsignaturerna, eller för den delen att fånga och kasta vidare som ett unchecked exception, d..v.s. ett RunTimeException eller något sub-exception (vilket är en ganska populär strategi som används bl.a. av ramverket Spring).
Ett intressant konstaterande (vilket framgår av kodexemplet i sidan som länkas nedan) är också att om du definierar ett Java-interface med en metodsignatur som inte deklarerar ett checked exception så kan ändå ett sådant exception (t.ex. IOException) uppstå om du implementerar interfacet med en Scala-klass.
När du implementerar interfacet med en Java-klass däremot så kan inte ett sådant exception kastas vidare eftersom man då får kompileringsfel, och för att slippa tvingas propagera checked exceptions så är det inte helt ovanligt att man i java-kod fångar ett checked exception och kastar vidare ett annat (unchecked exception) för att slippa propageringen via metodsignaturerna.
För ett konkret kodexempel, se följande sida med engelska kommentarer:
Scala does not implement the concept of checked exceptions
/ Tomas Johansson, 2010-01-19