In our tests, we make extensive use of stubs, some of which create and throw exceptions. I'm finding that just instantiating an exception, is causing a stacktrace to show up when our tests run. This means that there's a large amount of unnecessary and confusing noise, as we don't care about these 'expected' exceptions. I've scoured the internet, but can't find anything about silencing these stacktraces (bare in mind, that actual exceptions, thrown elsewhere within the code, or by the framework, I'd like to still show traces for). Is this a common issue and has anyone found a way around it?
Sorry, with example:
val t = new Throwable("Expected exception")
val service = new AuthenticationService()(ExceptionThrowingClient(t))
Results in a test run with a stacktrace that looks something like this:
java.lang.Throwable: Expected exception
at services.auth.AuthenticationServiceSpec$$anonfun$4.apply(ServiceSpec.scala:104) ~[test-classes/:na]
at services.auth.AuthenticationServiceSpec$$anonfun$4.apply(ServiceSpec.scala:103) ~[test-classes/:na]
at org.specs2.mutable.SideEffectingCreationPaths$$anonfun$executeBlock$1.apply$mcV$sp(FragmentsBuilder.scala:292) ~[specs2-core_2.10-2.3.12.jar:2.3.12]
at org.specs2.mutable.SideEffectingCreationPaths$class.replay(FragmentsBuilder.scala:264) ~[specs2-core_2.10-2.3.12.jar:2.3.12]
at org.specs2.mutable.Specification.replay(Specification.scala:12) ~[specs2-core_2.10-2.3.12.jar:2.3.12]
Which traces back to the point of instantiation within the spec.
Related
Coming from a .NET world where throwing an exception when the error is on the user side (like validation) is considered to be a bad practice, it appears really weird to see many instances of it in different articles and GitHub examples.
Is there any mechanism in Dart that makes stack tracing less expensive, or in Dart throwing an exception for something like input validation is bad practice as well?
As you said, exceptions should be used mainly for exceptional paths. Validation is actually a some part of program domain.
I did a very simple test - returning result vs exception. https://gist.github.com/jposert/0cbf824ac625a6563c2f62085eda64e8
The test isn't statistically correct but i think it shows that even though theres an difference in times - in context of the software it probably doesn't matter.
However, for sure it's incorrect from architectural point of view to throw instead of return.
I was looking at scala.util.control.NonFatal. I can't find the source, but I believe it is something like this.
They are declaring LinkageError as Fatal ...
Tomcat (at least last few years I used it) always returned 500 on catch Throwable, rather than crashing on certain kinds of errors. So do many other systems that make a best effort to always return something to the client.
So, my end question is when would you use NonFatal instead of making a best-effort attempt to provide some response?
As an example, now Futures in Twitter's Future library end up not resolving on NoSuchMethodError so my Future no longer resolves as failed with a Throwable but instead throw up the stack (differently from RuntimeException). In fact, in the open source Finagle stack, a NoSuchMethodError will cause the client socket connection to close on the client with no 500 http error back to customer. Customer then thinks 'hmm, network issue maybe ... why did my socket close'
So far, it has caused me nothing but issues and I admit to be a little frustrated, but need to be open to more use cases. For years, KISS and treating every Throwable in the catchall as non fatal has worked, but NonFatal is implying there are use-cases where we should do something different.
The source code of NonFatal is linked from the API docs.
Fatal errors are those from which your system or the JVM will most likely not recover correctly, so catching those errors is not a good idea.
The sub-classes of LinkageError are: ClassCircularityError, ClassFormatError, ExceptionInInitializerError, IncompatibleClassChangeError, NoClassDefFoundError, UnsatisfiedLinkError, VerifyError. These all occur when your class path is broken, there are invalid or binary incompatible class files. It's safe to assume that your entire system is broken if these happen at runtime.
To answer the question: You should "let it crash". Always use a NonFatal pattern match when you need a catch-all clause. It will also do you the favour and handle control-flow related exceptions correctly (e.g. NonLocalReturnControl).
Note that unlike the old source you link to, StackOverflowError is not non-fatal any longer, the decision was revised in Scala 2.11 as per SI-7999.
I got this cute error, that has no stack trace associated with it in play's log file (nor in the console).
[ERROR] [03/14/2015 19:36:46.713] [play-akka.actor.default-dispatcher-7] [ActorSystem(play)] Uncaught error from thread [play-akka.actor.default-dispatcher-7] (scala.runtime.NonLocalReturnControl)
[error] a.a.ActorSystemImpl - Uncaught error from thread [play-akka.actor.default-dispatcher-7]
scala.runtime.NonLocalReturnControl: null
Does this represent a promise/future that crashed, but has no thread any longer waiting for it other than akka's dispatcher? how can I nonetheless trace the error in my code without attaching a debugger session?
Attaching a debugger, it seems that using a return inside Future map composition caused the NonLocalReturnControl error. Oddly and unfortunately though, the stack trace doesn't propagate to the console/log in this case in my case. The stack at the moment a NonLocalReturnControl is created can be seen in a debugger, but akka/play somehow don't provide it.
Alas, this type of error's stack trace is suppressed by default. Turns out quite amazingly that scala internally implements function return value propagation by internally throwing and catching this exception type (up until Scala 2.11 at least). Hence the special suppression... Tough luck.
The same exception arises when using return in a future, which is obviously a mistake, but the internal architecture's use of this suppressed exception, makes debugging this particular case, well, suck. Check you don't use return in asynchronous code if you get this error, and avoid using return as much as you can so it is less likely this will pop up in your code when turned asynchronous.
In regard to potential runtime failures, like database queries, it seems that one must use some form of Either[String, Option[T]] in order to accurately capture the following outcomes:
Some (record(s) found)
None (no record(s) found)
SQL Exception
Option simply does not have enough options.
I guess I need to dive into scalaz, but for now it's straight Either, unless I'm missing something in the above.
Have boxed myself into a corner with my DAO implementation, only employing Either for write operations, but am now seeing that some Either writes depend on Option reads (e.g. checking if email exists on new user signup), which is a majorly bad gamble to make.
Before I go all-in on Either, does anyone have alternate solutions for how to handle the runtime trifecta of success/fail/exception?
Try Box from the fantastic lift framework. It provides exactly what you want.
See this wiki (and the links at the top) for details. Fortunately lift project is well modulized, the only dependency to use Box is net.lift-web % lift-common
Use Option[T] for the cases records found and no records found and throw an exception in the case of SQLException.
Just wrap the exception inside your own exception type, like PersistenceException so that you don't have a leaky abstraction.
We do it like this because we can't and don't want to recover from unexpected database exceptions. The exception gets caught on the top level and our web service returns a 500 Internal server error in such case.
In cases where we want to recover we use Validation from scalaz, which is much like Lift's Box.
Here's my revised approach
Preserve Either returning query write operations (useful for transactional blocks where we want to rollback on for comprehension Left outcome).
For Option returning query reads, however, rather than swallowing the exception with None (and logging it), I have created a 500 error screen, letting the exception bubble up.
Why not just work with Either result type by default when working with runtime failures like query Exceptions? Option[T] reads are a bit more convenient to work with vs Either[Why-Fail, Option[T]], which you have to fold/map through to get at T. Leaving Either to write operations simplifies things (all the more so given that's how the application is currently setup, no refactoring required ;-))
The only other change required is for AJAX requests. Rather than displaying the entire 500 error page response in the AJAX status div container, we check for the status type and display 500 error message accordingly.
if(data.status == 500)
$('#status > div').html("an error occurred, please try again")
Could probably do an isAjax check server-side prior to sending the response; in which case I can send back only status + message rather than the error page itself.
Many of the Caché API methods return a %Status object which indicates if this is an error. The thing is, when it's an unknown error I don't know how to handle (like a network failure) what I really want to do is "throw" the error so my code stops what it's doing and the error gets caught by some higher level error handler (and/or the built-in %ETN error log).
I could use ztrap like:
s status = someObject.someMethod()
ztrap:$$$ISERR(status)
But that doesn't report much detail (unlike, say, .NET where I can throw an exception all the way to to the top of the stack) and I'm wondering if there are any better ways to do this.
Take a look at the Class Reference for %Exception.StatusException. You can create an exception from your status and throw it to whatever error trap is active at the time (so the flow of control would be the same as your ZTRAP example), like this
set sc = someobj.MethodReturningStatus()
if $$$ISERR(sc) {
set exception = ##class(%Exception.StatusException).CreateFromStatus(sc)
throw exception
}
However, in order to recover the exception information inside the error trap code that catches this exception, the error trap must have been established with try/catch. The older error handlers, $ztrap and $etrap, do not provide you with the exception object and you will only see that you have a <NOCATCH> error as the $ZERROR value. Even in that case, the flow of control will work as you want it to, but without try/catch, you would be no better off than you are with ZTRAP
These are two different error mechanisms and can't be combined in this way. ztrap and %ETN are for Cache level errors (the angle bracket errors like <UNDEFINED>). %Status objects are for application level errors (including errors that occurred through the use of the Cache Class Library) and you can choose how you want to handle them yourself. It's not really meaningful to handle a bad %Status through the Cache error mechanism because no Cache error has occurred.
Generally what most people do is something akin to:
d:$$$ISERR(status) $$$SomeMacroRelevantToMyAppThatWillHandleThisStatus(status)
It is possible to create your own domain with your own whole host of %Status codes with attendant %msg values for your application. Your app might have tried to connect to an FTP server and had a bad password, but that doesn't throw a <DISCONNECT> and there is no reason to investigate the stack, just an application level error that needs to be handled, possibly by asking the user to enter a new password.
It might seem odd that there are these two parallel error mechanisms, but they are describing two different types of errors. Think of one of them being "platform" level errors, and the other as "application level errors"
Edit: One thing I forgot, try DecomposeStatus^%apiOBJ(status) or ##class(%Status).LogicalToOdbc(status) to convert the status object to a human readable string. Also, if you're doing command line debugging or just want to print the readable form to the principal device, you can use $system.OBJ.DisplayError(status).