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.
Related
So the issue I'm having only recently started after an update to the Lync client somewhere around version 15.0.4849.1000. The issue revolves around app sharing conferences, which I have working fine still in 2016 SFB and anything prior to 15.0.4849.1000.
The core issue as far as I can tell deals with Modality.BeginConnect, the passed in callback does not get called. Although, I have had it get called when I'm debugging, stepping through the code and hitting breakpoints, etc. So that leads me to think that normally maybe something's not getting initialized in time, or some sort of race condition, but I haven't been able to pin down exactly what makes it function correctly in that case.
EDIT: I just realized another exception occurs during the call to BeginConnect:
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in Microsoft.Lync.Model.dll
Additional information: Exception from HRESULT: 0x80F10083
And that HRESULT translates to: "The operation is disabled by capability". What in the world does that mean?
The odd thing is (or seems odd to me) that even though the callback is never called, I do receive a ModalityStateChanged event for ModalityState.Connected...
So if you have any ideas what would perhaps cause that, please share!
I don't think these this is related, but a call to this:
m_aeConversationWnd = AutomationElement.FromHandle(m_ConversationWindow.Handle);
shortly before calling BeginConnect, fails with the exception:
A first chance exception of type 'System.ArgumentException' occurred in UIAutomationClientsideProviders.dll
Additional information: Value does not fall within the expected range.
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.
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 am not able to understand the places where an error handling or where an exception handling should be used. I assume this, if it is an existing framework class there are delegate methods which will facilitate the programmer to send an error object reference and handle the error after that. Exception handling is for cases where an operation of a programmer using some framework classes throws an error and i cannot get an fix on the error object's reference.
Is this assumption valid ? or how should i understand them ?
You should use exceptions for errors that would never appear if the programmer would have checked the parameters to the method that throws the exception. E.g. divide by 0 or the well known "out of bounds"-exception you get from NSArrays.
NSErrors are for errors that the programmer could do nothing about. E.g. parsing a plist file. It would be a waste of resources if the program would check if the file is a valid plist before it tries to read its content. For the validity check the program must parse the whole file. And parsing a file to report that it is valid so you can parse it again would be a total waste. So the method returns a NSError (or just nil, which tells you that something went wrong) if the file can't be parsed.
The parsing for validity is the "programmer should have checked the parameters" part. It's not applicable for this type of errors, so you don't throw a exception.
In theory you could replace the out of bounds exception with a return nil. But this would lead to very bad programming.
Apple says:
Important: In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object.
I think you are absolutely right with your assumption for Errors and for it framework provide a set of methods (UIWebView error handling ), But your assumption for Exception partially right because the exception only occurred if we do something wrong which is not allowed by the framework and can be fixed. (for example accessing a member from an array beyond its limit).
and will result in application crash.
Apologies if this question has already been answered somewhere else, but I could not find any decisive answer when searching on it:
I'm wondering when try-catch blocks are to be used in objective-c iPhone applications. Apple's "Introduction to the Objective-C Programming Language" state that exceptions are resource intensive and that one should "not use exceptions for general flow-control, or simply to signify errors." From reading a few related questions here I also gather that people are not often using this method in practice.
So I guess the question is: what are the situations when it's appropriate to use try-catch blocks when developing for iPhone/Objective-C and when should they absolutely NOT be used?
For example, I could use them to catch beyond bounds and other exceptions when working with objects in arrays. I have a method which performs are few tasks with objects that are passed on in a number of arrays. The method returns nil if an error has occurred and a try-catch block could help me catch exceptions. However, I could of course simply write little if-tests here and there to ensure that I, for instance, never try to access an index beyond an arrays bounds. What would you do in this situation?
Thanks a lot!
It is only appropriate to use #try/#catch to deal with unrecoverable errors. It is never appropriate to use #throw/#try/#catch to do control-flow like operations.
In particular, it would not be appropriate to use for catching out-of-bounds exceptions unless your goal is to catch them and somehow report the error, then -- typically -- crash or, at the least, warn the user that your app is in an inconsistent state and may lose data.
Behavior of any exception thrown through system framework code is undefined.
Your if-test to do bounds checking is a far more appropriate solution.
#bbum's answer is absolutely correct (and he would know the answer better than most). To elaborate a bit...
In Cocoa, you should generally avoid using exceptions (#try/#catch[/#finally]) for flow control. As you mention, exceptions carry an unusually large cost (compared to run-times such as JVM or the CLR optimized for exception use). Furthermore, most of the Cocoa frameworks are not exception safe. Thus, throwing an exception through Cocoa framework code is dangerous and will likely cause odd, difficult to diagnose, and catastrophic (think possible data loss) bugs in your app.
Instead of using exceptions, Cocoa code uses NSError to signal error conditions that are recoverable within the application. Exceptions are used to signal conditions from which your application cannot recover. Thus a UI component requesting an out-of-bounds position in a model array could be signaled with an error (presented to the user with a reason their request could not be completed) while attempting to access an out-of-bounds position given an index that you think should be valid signals an exceptional condition where you app is in an inconsistent state and should probably die as soon as possible before it can do more damage.
NSParameterAssert, for example signals with an NSException when an assertion fails.
So when should you use exceptions or #try/#catch? If you're using a C/C++ library that makes use of exceptions, you should catch those exceptions before they can get thrown back through Cocoa code. Similarly, if you are serious about consistency of state within your application, you should raise an exception as soon as you detect that your state is inconsistent (and unrecoverable).