I know that the implementation signals a MessageNotUnderstood exception, but how does that end up opening a debugger?
When an Exception remains unhandled after it has been signalled, its #defaultAction is invoked. MessageNotUnderstood>>defaultAction delegates to Error>>defaultAction, which signals an UnhandledError (another Exception). This exception, in turn, has a defaultAction whose code reads like this:
^ ToolSet debugError: self exception
...which opens the debugger if you use the StandardToolSet (which is the default in regular Squeak images).
Related
Its very basic, and its boggling my mind now.
The specific exception message that i see is :
java.lang.ClassCastException
com.company.client.vehicle.model.PerceivedGarageMessageDTO cannot be cast to com.company.client.vehicle.model.PerceivedGarageMessageDTO
The code looks like this
PerceivedGarageMessageDTO p = (PerceivedGarageMessageDTO)obj;
I am using Intellij.
When i view obj in intellij watcher, i see the relevant properties inside obj.
When i evaluate PerceivedGarageMessageDTO p = (PerceivedGarageMessageDTO)obj in evaluate mode, the execution goes fine and the object is typecasted.
When i execute the command in normal debug run by pressing F8, an exception is thrown.
I am unable to figure out the cause of this very very strange issue.
Usually this happens when the class is loaded with different classloaders.
Will fix debugger evaluator within IDEA-203275.
I created a new Windows Store app project using the Grid App (XAML) template. I ran the project (in debug mode) without changing a single line of code. While it was running, I switched back to Visual Studio and clicked the Suspend button in the toolbar.
At this point, the app threw a SuspensionManagerException. The exception’s details weren’t too helpful. The message is SuspensionManager failed. It has the (so far) unhelpful HResult -2146233088. It also has an InnerException that’s just as unhelpful. Its message is Error HRESULT E_FAIL has been returned from a call to a COM component. and its HResult, which is -2147467259, is even worse than the outer exception’s HResult.
The line of code that throws the exception is in the SuspensionManager, which, again, is part of the project template. Here’s the line:
StorageFile file = await ApplicationData.Current.LocalFolder.CreateFileAsync(sessionStateFilename, CreationCollisionOption.ReplaceExisting);
The part that triggers the exception is LocalFolder.CreateFileAsync(…). The MSDN documentation for the CreateFileAsync method has a “Remarks” section that reads: If you try to create a file in a virtual folder like a library or a file group, this method may fail.
That’s it. There’s no explanation of why it may fail, or a description of the conditions under which it may fail, or what you can do about it.
As it happens, even when it fails, the file is actually created. The file in question is called _sessionState.xml and is located at C:\Users\<username>\AppData\Local\Packages\<package_id>\LocalState. If I delete the file and re-suspend the app, the exception is throw again and the file is recreated.
I've searched high and low and haven't found anything conclusive. The CreateFileAsync method is a projection, so I can't easily disassemble it or figure out why it "may fail".
Does anybody have any idea what could be causing this problem, or how to go about debugging or solving it?
The first thing to check is that Frame.Navigate should only take primitives as its parameter argument.
Also, make sure you are calling GetDeferral in your async event handler.
How do I go about finding out where in my code caused the following exception?
2012-08-15 09:24:27.414 TestProject[82870:17303] -[TestObj doIt]: unrecognized selector sent to instance 0x1106f320
Best way to do it: Add a breakpoint to capture all exceptions, that will give you the line of code where you are getting the exception. From the console, you will get the same message you are posting on your question, so, use the pointer address to print the object that is getting the exception. If the object is garbage(the debugger wont print it), that means you are overreleasing an object. If you have zombies enabled, you will find a prefix NSZombie__ on your class name. That also means overrelease. If you get a different class than the one you are expecting, you are switching the objects at some point and sending a message to the wrong object.
Go to the breakpoints navigator (on the left)
at the bottom you have a +,
add an exception breakpoint on all exceptions
set a breakpoint for thrown exceptions. by default, it will pause when an exception is thrown -- there you will see the backtrace and values.
if it's completely random (e.g. not reproducible), then you may have best luck running Instruments with zombies enabled.
This may be a debugger issue, but here goes:
I have this piece of code:
Private Function Connect() As Boolean
Try
sessionBegun = False
connectionOpen = False
rp = New RequestProcessor2()
rp.OpenConnection2("","EZSystem", QBXMLRPConnectionType.localQBD)
connectionOpen = True
ticket = rp.BeginSession("", QBFileMode.qbFileOpenDoNotCare)
sessionBegun = True
Return True
Catch e As COMException
exceptionHandler.HandleConnectionException(e)
**Throw New QuickBooksConnectionException(e.Message)**
End Try
End Function
My intention is to 'convert' the low level exception into something more meaningful, so I throw an exception of my own creation. I want this to bubble up to a place where I can handle it.
However what is happening is my debugger breaks and tells me that an exception of type "QuickBooksConnectionException" was thrown.
I know that, I just threw it, why are you catching it?
From what I've read, this ought to work, and there doesn't appear to be an analogous Java throws keyword, so perhaps it is my debugger.
I am using SharpDevelop.
Thanks,
Dane
As written, your code throws an unhandled exception, which is always going to cause the debugger to balk. You just have to catch the QuickBooksConnectionException in the code that invokes this method. (And you're right, there's no equivalent in C# to the throws Java keyword.)
You can change the setting for when the debugger breaks for exceptions.
See here.
This is just the debugger doing its job. It usually catches any unhandled exceptions. I think your code is working fine, it's the debugger that's maybe confusing you.
Here's an experiment to show what's going on. Remove your Try-Catch block completely. Run the code & cause a COMException. The debugger will "catch" it, because it's unhandled, and highlight the line that throws it.
An exception bubbles up the call stack looking for an enclosing Try block. If there's no enclosing Try block, then the runtime deals with it. Which means that if you are running under a debugger, the debugger will rewind the call stack back so it can show you the original line that threw the exception. To help you debug why the exception happened. Try running from a standalone EXE or website with no debugger. It will terminate with a standard error dialogue.
Here are the rules that determine whether the debugger breaks on an exception.
A friend of mine discovered some strange behaviour with NSDictionary, and I'm curious as to why it happens. Consider the following code:
NSDictionary *dict = [[NSDictionary alloc] init];
// Oops, we can't mutate an NSDictionary
[dict setObject:[[NSNull alloc] init] forKey:#"test"];
NSLog(#"Set");
The code produces a warning upon compilation that "'NSDictionary' may not respond to 'setObject:forKey:'". That's all well and good, and if you run it anyway, you'll get this output in the console:
-[__NSCFDictionary setObject:forKey:]: mutating method sent to immutable object
Again, exactly what you'd expect to happen. However, at this point the app does not crash or terminate due to an uncaught exception. The setObject:forKey: method simply never returns, and the app appears to hang; the following NSLog is never executed. If you try to step over or into the method using GDB, debugging just seems to end, but without any explicit error message. The app continues to run, but the debugger provides no clue as to where in the code the execution is "stuck."
What's going on here? What is the app actually doing in this case, and why doesn't it crash with an NSInternalInconsistencyException or something of the like?
Edit: For those who have asked, I'm running XCode 4.1 on OS X Lion (10.7.2), building with "Apple LLVM compiler 2.1." I'm using all of the default settings you get with a new Cocoa project in XCode 4. I experience the same non-crashing behaviour regardless of whether I debug the program or just "Run" it. Changing from Debug building to Release building makes no difference. I can even locate the .app file manually in Finder and double click on it to execute it outside of XCode, and it still does not crash.
Exceptions do not crash AppKit programs. NSApplication installs a default exception handler that catches exceptions that your code doesn't. Then you just go back into the runloop as normal.
Lots of apps exhibit this behaviour. It's a common cause of inexplicable blank views/windows. If an exception happens before a view manages to finish drawing, the view will be blank, but the app won't crash. Exceptions only cause a crash if you deliberately change the default exception handler to crash.