Silverlight 3 XamlReader Exception not caught

Question

Hi,

when I use XamlReader.Load() with an invalid XAML string, the resulting XAMLParseException is not caught although beeing in a try-catch-block:

 try
 {
        UIElement xamlCode = XamlReader.Load(XamlText) as UIElement;
 }
 catch (Exception ex)
 {
        ErrorText = ex.Message;
 }

The code is called from the Tick-Event of a DispatcherTimer, but also in Events like MouseLeftButtonDown the exception is not caught resulting in a break in the Line where I call .Load().

Does anyone know how to catch this Exception and resume normal programm activity?

Thanks, Andrej

Answer 1

It is completely unfathomable that this code would not catch the exception. How do you determine that the XAMLParseException is occuring here? Are you sure is not coming from some other Xaml Load in the project?

Answer 2

Is this always the case ? or onlys while debugging ?

I'm aware this is an extremely late answer and you might have found the solution to it, for as reference to people finding your question similar to theirse (like my case ), my answer might still be of use.

If its happening while debuggin, it might be because the exeption is configured to be thrown.

You can change this:

1. Customize the Debug menu, adding the "Exceptions" command to it.
2. In the Exceptions configuration, Drill down to System.Windows.Markup.XamlParseException, which is under Common Language Runtime Exceptions.
3. Remove the check from the "Throw" column.

Answer 3

There are various Silverlight operations that get "re-marshalled" onto separate threads for what are presumably various good and sufficient reasons. It looks kind of like this:

Dispatcher.BeginInvoke(() => LoadSomeXamlOrSomething());

Any exception thrown within LoadSomeXamlOrSomething() won't be caught by normal try/catch blocks. This happens even in SL 4 with things like loading images with invalid formats. It's annoying, and MS needs to come up with a better way to handle this, for instance, by letting you register an exception handler when you make the call.

Until MS figures this out, your options are:

• Fix the underlying XAML error.
• Catch the exception in App.Application_UnhandledException.