Most of the stack trace is missing when test fails with an exception

[GoogleCodeExporter]

What steps will reproduce the problem? If possible, provide source code and 
stack trace.

When the tested code throws an exception, it doesn't tell me the whole stack 
trace. For example, I am geting this:

java.lang.NullPointerException: The calculation factor is null.
    at Geral.Util.Util.validateNotNull(Util.java:350)
    at CalcModule.Calculation.SpecCalculation.The Calculation factor should be positive.(SpecCalculation.groovy:75)

The test is not calling Util.java directly, so where is the rest of the stack 
trace? Without all the stack information it gets very difficult to find out 
what is the problem with the code.

What version of Spock and Groovy are you using?

Using Spock 0.5; Groovy 1.8; IntelliJ IDEA 10.5.

Original issue reported on code.google.com by marcglas...@gmail.com on 11 Aug 2011 at 2:02

• Merged into: #187

[GoogleCodeExporter]

Spock filters the stack trace to get rid of all the Groovy and JUnit internals 
(Groovy stack traces can easily have more than 100 lines). If it filters too 
much in your case, it would be interesting to know what's missing. To disable 
the filtering, add the following to ~/.spock/SpockConfig.groovy:

runner.filterStackTrace false

By the way, you shouldn't use spock-core-0.5-groovy-1.8 anymore because it was 
based on a pre-release version of Groovy 1.8. Until 0.6 is out, the only safe 
bet (for Groovy 1.8) is spock-core-0.6-groovy-1.8-SNAPSHOT, which is available 
from http://m2repo.spockframework.org/snapshots.

Original comment by pnied...@gmail.com on 11 Aug 2011 at 4:10

[GoogleCodeExporter]

Hmm, so the filter is necessary. However, it is not to be working properly.
It is filtering more than just Groovy and JUnit stuff.
BTW, sorry for that, but I am indeed already
using spock-core-0.6-groovy-1.8-**SNAPSHOT.

Original comment by marcglas...@gmail.com on 11 Aug 2011 at 5:11

[GoogleCodeExporter]

Could you post the full stack trace, and the stack trace you'd like to see? A 
reproducible example would be even better.

Original comment by pnied...@gmail.com on 11 Aug 2011 at 5:19

[GoogleCodeExporter]

Here it is:

java.lang.NullPointerException: Um dos par�metros � nulo.
at Geral.Util.Util.validaNaoNulos(Util.java:350)
at ModuloAtivos.Operacao.Operacao$Builder.preenche(Operacao.java:518)
at
ModuloAtivos.Operacao.Operacao$Builder.antesDePersistir_passo1(Operacao.java:582
)
at
ModuloAtivos.Operacao.Operacao$Builder.antesDePersistir_passo1(Operacao.java:446
)
at Geral.Objetos.Registro$Builder.constroiEPersiste(Registro.java:556)
at Geral.Objetos.Registro$Builder.constroiEPersiste(Registro.java:607)
        at
ModuloAtivos.Clearing.SpecClearingGroovy.XXXTest.(SpecClearingGroovy.groovy:75)

Original comment by marcglas...@gmail.com on 11 Aug 2011 at 5:52

[GoogleCodeExporter]

This looks different from the stack trace you posted before. Are you saying 
that the calls to Operacao.Builder and Registro.Builder are missing from the 
filtered stack trace?

Original comment by pnied...@gmail.com on 11 Aug 2011 at 5:56

[GoogleCodeExporter]

It's the same problem. It only tells me the first line and the last line:

java.lang.NullPointerException: Um dos par�metros � nulo.
at Geral.Util.Util.validaNaoNulos(Util.java:350)
        at
ModuloAtivos.Clearing.SpecClearingGroovy.XXXTest.(SpecClearingGroovy.groovy:75)

Maybe some problem when processing the stack inside inner classes? All
removed lines are from inside inner classes, and they contain a dollar sign:
"Operacao$Builder"...

Original comment by marcglas...@gmail.com on 11 Aug 2011 at 6:01

[GoogleCodeExporter]

Yes, inner classes is likely the problem. I'll have a look.

Original comment by pnied...@gmail.com on 11 Aug 2011 at 6:15

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by pnied...@gmail.com on 11 Aug 2011 at 6:18

• Changed state: Duplicate