XamlParseException was unhandled - wcf

I faced the problem debugging my WPF-WCF simple chat application. There's an exception like:
Blockquote XamlParseException was unhandled. 'The invocation of the constructor on type 'ChatGUI.MainWindow' that matches the specified binding constraints threw an exception.' Line number '3' and line position '9'.
I see that's a XAML exception, so here's the XAML code listing:
http://www.codeproject.com/Questions/310851/XamlParseException-was-unhandled
Have you ever seen the same problem? I would be glad to see every useful advice.
Thanks in advance.

The XamlParseException can be a little bit misleading. Check if you're doing something in the constructor of your class MainWindow that throws an exception. This will cause the same behavior. Unfortunately the debugger won't break at the real initiater but show you this error.
E.g. use an try catch state statement in the constructor, the catch block will show you the exception.

Related

Visual Studio giving generic debug errors, but gives specific errors out of debug

I don't even know what to call this, but here's the situation - I use Visual Studio 2013 to create a Windows Forms Project. At some point, the debugger started throwing out this error:
An unhandled exception of type 'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
Additional information: Exception has been thrown by the target of an invocation.
However, I happened to notice that when I run the program without debugging, and the error occurs, it gives me:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
It's not a complicated program, I'm not doing anything like multithreading or delegating yet. No matter what I try, it only gives the first error. I've gotten it when I was try to delete a file that didn't exist, when the index was out of bounds, when a control threw an error. All these errors just quoted the first one in debug mode, but the normal errors out of debug mode.
I just threw the code in another project and it works fine. Maybe it's a option in the debugging menu, but I've tried everything I could imagine. I also tried updating to VS2013 Update 4 and it still does it. Help?
An unhandled exception of type 'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
Additional information: Exception has been thrown by the target of an invocation.
A TargetInvocationException is a wrapper around the actual exception.
"The client application's event-handler delegate should check the Error property; otherwise, the property will raise a TargetInvocationException"
Try returning a try catch and get the ex.InnerException
and see why it is giving this error
System.IndexOutOfRangeException: Index was outside the bounds of the array.
try this as well
try {
//here you read the arguments and pass to a variable
}
catch(System.IndexOutOfRangeException) {
//other codepart
}
Hope this helps

System.ArgumentException, Value does not fall within the expected range in metro app

I am getting this exception, I have no clue whatsoever why it throws this ArgumentException.
Does anybody have an idea what is that can cause this exception to occur in a metro app?
Is it due to any mistake in XAML design or is it something else?
You might be setting Selector.SelectedItem in a ComboBox, ListView, etc. to a value that is not actually in the bound ItemsControl.ItemsSource collection.
Try this method, if there are no obvious issues in your code/xaml

How to find out the location of unrecognized selector exception in Objective-C?

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.

org.eclipse.xtext.linking.impl.IllegalNodeException popups an error instead of just being written to the log

I am writing an editor based on xtext. (v 2.2.1)(Eclipse Indigo)
I have a class that extends DefaultLinkingServic and overrides the method:
public List getLinkedObjects(EObject context, EReference ref, INode node) throws IllegalNodeException.
The method throws IllegalNodeException when an object cannot be resolved.
When the exception is thrown (and it should be thrown) the error is not only written to the error log, but it causes a popup window to appear with the error:
An internal error occurred during: "Xtext validation".
org.eclipse.xtext.linking.impl.IllegalNodeException: Action App.f is not applicable for the specified arguments.
This is very problematic especiallyif the file has multiple errors which makes it impossible to edit anything in the editor, since the popup repeatedly appears on screen.
This problem is consistent in several IDE's but in others is not reproducible.
Any help would be greatly appreciated.
You are stumbling accross this bug which was already fixed for 2.3 (due June).
As a workaround, you may want to bind a custom implementation of the LazyLinkingResource and catch the IllegalNodeException in #getEObject. Alternativley you could return an empty list from your custom LinkingService instead of raising an IllegalNodeException.

Thrown custom exception is immediately caught in the same catch block it is thrown from

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.