search

jmockit / jmockit1

Advanced Java library for integration testing, mocking, faking, and code coverage
Other
461 stars 239 forks source link

Horrible stack trace inspection hack unsurprisingly backfires #195

Closed dmlloyd closed 9 years ago

dmlloyd commented 9 years ago

JMockit 1.10, Java(TM) SE Runtime Environment (build 1.8.0_45-b14)

In the class mockit.internal.util.StackTrace, there is a nasty reflection-based hack to call Throwable.getStackTraceElement(int), which is a non-public, native method found in some JDKs. Unfortunately, if you override the stack trace in an exception, as some frameworks (like JMockit itself, ironically) do for user-friendliness purposes, the stack frames yielded by this method do not match the frames from the real, contractually-guaranteed-API stack trace. This causes the mockit.internal.util.StackTrace#filter() method to butcher the stack trace in arbitrary ways, making it impossible to figure out what your failing test died of.

There really is no reason to use this bizarre, unsupported, and unsupportable approach to collecting the stack trace.

dmlloyd commented 9 years ago

Ah looked like it was already fixed by #110 - nice!