Exception in composited specs get's eaten up

[GoogleCodeExporter]

Hi Eric,

I got a new bug / enhacement proposal for you:

*What steps will reproduce the problem?*
1. Run the attached CompositeSpec.scala with specs (Or use the attached sbt 
project. Then: "sbt update" and "sbt test")

*What is the expected output? What do you see instead?*
*Expected:* Something like:
Could not create an instance of CompositeSpec, because of:
  java.lang.Exception: Something bad happened

The current behavior is very misleading in my opinion. The caught exception's 
detail message should be printed. However, currently specs just prints "0" as 
the cause.

*What happens actually:*
[error] Could not create an instance of CompositeSpec
[error] 
[error]   0
[error] 
[error]   org.specs.util.Classes$class.createInstanceFor(Classes.scala:76)
[error]   org.specs.util.Classes$.createInstanceFor(Classes.scala:27)
[error]   org.specs.util.Classes$class.create(Classes.scala:38)
[error]   org.specs.util.Classes$.create(Classes.scala:27)
[error]   org.specs.runner.TestInterfaceRunner.run(TestInterfaceRunner.scala:55)
[error]   sbt.TestRunner.run(TestFramework.scala:52)

(and so on)

*What version of the product are you using? On what operating system?*
specs 1.6.6 (NOT the snapshot)
on scala 2.8.1
on linux (Fedora 12), 64 Bit, OpenJDK 1.6.0_18 Server

Cheers
~ Philipp

Original issue reported on code.google.com by phdoerfler@gmail.com on 8 Dec 2010 at 7:50

• Merged into: #165

Attachments:

• ScratchPad.tar.gz

[GoogleCodeExporter]

Isn't it what issue 165 is about? Can you please try the snaspshot?

Thanks.

Original comment by etorrebo...@gmail.com on 8 Dec 2010 at 8:10

[GoogleCodeExporter]

Yes I confirm that this issue is fixed with the latest snapshot.

Original comment by etorrebo...@gmail.com on 8 Dec 2010 at 8:47

• Changed state: Duplicate

[GoogleCodeExporter]

I've just now tried it again with 1.6.7-SNAPSHOT but nothing changes.
The specs jar in use is:
http://scala-tools.org/repo-snapshots/org/scala-tools/testing/specs_2.8.1/1.6.7-
SNAPSHOT/specs_2.8.1-1.6.7-SNAPSHOT.jar

sbt clean-cache
sbt update
sbt test

And there is still this weird "0" appearing in the stacktrace exactly as before.

Did I miss something?

Greetings,
~ Philipp

Original comment by phdoerfler@gmail.com on 8 Dec 2010 at 9:20

[GoogleCodeExporter]

Can you make sure that you remove the old specs jars in your lib_managed 
directory? Because even if I do clean-cache, the jars in that directory are not 
removed. So maybe you still have the old jar taking precedence in there.

Original comment by etorrebo...@gmail.com on 9 Dec 2010 at 12:10

[GoogleCodeExporter]

That's what I did:

$ find | grep specs
./lib_managed/scala_2.8.1/compile/specs_2.8.1-1.6.7-SNAPSHOT.jar

$ sbt clean-cache
(snip)

$ find | grep specs
./lib_managed/scala_2.8.1/compile/specs_2.8.1-1.6.7-SNAPSHOT.jar

$ rm -r lib_managed/

$ find | grep specs

$ sbt clean
(snip)

$ sbt update
[info] Building project ScratchPad 1.0 against Scala 2.8.1
[info]    using ScratchPadProject with sbt 0.7.4 and Scala 2.7.7
[info] 
[info] == update ==
[info] downloading 
http://scala-tools.org/repo-snapshots/org/scala-tools/testing/specs_2.8.1/1.6.7-
SNAPSHOT/specs_2.8.1-1.6.7-SNAPSHOT.jar ...
[info]  [SUCCESSFUL ] 
org.scala-tools.testing#specs_2.8.1;1.6.7-SNAPSHOT!specs_2.8.1.jar (20830ms)
[info] :: retrieving :: me#scratchpad_2.8.1 [sync]
[info]  confs: [compile, runtime, test, provided, system, optional, sources, 
javadoc]
[info]  1 artifacts copied, 0 already retrieved (2796kB/36ms)
[info] == update ==
[success] Successful.
(snip)

$ sbt test
(snip)
[info] == CompositeSpec ==
[error] Could not create an instance of CompositeSpec
[error] 
[error]   0
[error] 
[error]   org.specs.util.Classes$class.createInstanceFor(Classes.scala:85)
[error]   org.specs.util.Classes$.createInstanceFor(Classes.scala:29)
[error]   org.specs.util.Classes$class.create(Classes.scala:40)
[error]   org.specs.util.Classes$.create(Classes.scala:29)
[error]   org.specs.runner.TestInterfaceRunner.run(TestInterfaceRunner.scala:55)
[error]   sbt.TestRunner.run(TestFramework.scala:52)
[error]   sbt.TestRunner.runTest$1(TestFramework.scala:66)
[error]   sbt.TestRunner.run(TestFramework.scala:75)
(snip)

(I just discovered that sbt clean-lib does clean the lib_managed directory)

If I do a sbt test without a prior sbt update (and therefore without the specs 
library), the compile fails as expected. So it seems that no other specs 
library is taking precedence here.

Hope this helps,
~ Philipp

Original comment by phdoerfler@gmail.com on 9 Dec 2010 at 3:37

[GoogleCodeExporter]

Oh, I just discovered that by changing the specification from:

object CompositeSpec extends Specification {
  "This bug".isSpecifiedBy(
    throw new Exception("Something bad happened")
  )
}

to:

class CompositeSpec extends Specification {
  "This bug".isSpecifiedBy(
    throw new Exception("Something bad happened")
  )
}

the issue goes away and sbt (and specs) now report:

[info] == CompositeSpec ==
[error] Could not create an instance of CompositeSpec
[error] 
[error]   Something bad happened
[error] 
[error]   CompositeSpec.<init>(CompositeSpec.scala:5)
[error]   sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

Which is the desired result.

To draw a conclusion: It seems that a specification can only yield meaningful 
exceptions when it's a class rather than an object.

Original comment by phdoerfler@gmail.com on 9 Dec 2010 at 3:41