-
-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Logging of exceptions #145
Comments
Can you give me an example of this? I don't see why this exception wouldn't be caught like any other error. What do you mean by "the spec itself throws an exception"? |
sure, get the tests for akka-patterns up and running (which might mean getting mongo/cassandra running locally) and run this spec. Make sure you have logging set up as described in logging.properties, which might mean running it from IntelliJ because of a bug in SBT (that they deny exists): then change the spec to expect a String or something, so that it fails. |
or, just create a very simple spec which has a stacktracefilter and throw an AssertionError. |
Can you please check the resolvers? I guess that you're having your own internal access to Artifactory but if I clone the akka-patterns project and build from scratch, |
Sam, I think I need to better understand what you mean by "the logging framework is bypassed"? Do you mean that the |
@etorreborre yeah, sorry... scalad isn't pushed to sonatype and it's not technically my project to do this (even though I wrote it). There is an issue for it, but I forgot to tell you: https://github.com/janm399/scalad/issues/7 |
@etorreborre that is what I mean by "the logging framework is bypassed" because inside the stacktracefilter is the only place I could hack in a logging hook. If you got rid of Specs2's own printing/logging/reporting of stacktraces and simply used JUL (or SLF4J), I'd be very happy. IMHO, stacktrace logging is the job of the logging framework. |
This is weird because when you add a |
@etorreborre I'll try to create a standalone spec that doesn't depend on akka-patterns and then share it with you. But I have quite a lot of year-end admin stuff to do today, so it might be tonight / tomorrow. To remind myself, I'm going to track this in https://github.com/fommil/scala-java-logging/issues/1 |
@etorreborre as promised, https://github.com/fommil/specs2-exceptions is a very small project demonstrating the problem. It is probably not the minimal testcase, but I think it is instructive to raise awareness for the hoops that one must go through to get reasonable logging in Scala. |
Thanks a lot to take some time to create a fully reproducible project, I'll try to get a look at that tomorrow. |
Wow, "tomorrow" eventually took 2 years and your specs2-exceptions project has moved on somewhere else. Is that still something that you are looking for? I was thinking that maybe you could use a custom |
😄 I guess I must have done a clean up at some point. To be honest I'm using scalatest these days so I don't have a need for this anymore, but thanks for checking up on it 😄 |
That's what I figured :-). Thanks for the update, I'm closing this issue now. |
This was originally discussed on the mailing list, but I would like to have a ticket against it so that I can track it in my own projects.
Original discussion: https://groups.google.com/d/msg/specs2-users/3cCUf-kUsaU/wgr5PEy1rTsJ
Basically, in order to correctly pass exceptions to the runtime logging infrastructure, a hacky
StacktraceFilter
must capture, log, and rewrite the stacktrace.Unfortunately, this doesn't seem to work when the spec itself throws an exception, such as Akka's
expectMsg
, and the logging framework is bypassed.Assuming the stack trace filtering is going to continue, I would recommend that all exceptions are passed to it, not just a subset.
The text was updated successfully, but these errors were encountered: