在WP7中使用FacebookApp.ApiAsync时,如何捕获FaceBookAPI异常?

在WP7中使用FacebookApp.ApiAsync时,如何捕获FaceBookAPI异常?,facebook,exception,exception-handling,windows-phone-7,facebook-c#-sdk,Facebook,Exception,Exception Handling,Windows Phone 7,Facebook C# Sdk,我目前正在使用FacebookC#sdkv4.2.1,并试图在用户墙上发布一些东西。它工作正常,直到我在验证访问令牌时遇到一个facebook OAuthException(OAuthException)错误。错误,我无法捕获该异常,它导致我的应用程序崩溃 我正在使用这个调用FacebookApp.apianc(“/me/feed”,…)。因为它是异步发生的,所以我不确定必须将try-catch块放在何处才能捕获该错误,但没有成功 这就是我正在使用的: private void shar

我目前正在使用FacebookC#sdkv4.2.1,并试图在用户墙上发布一些东西。它工作正常,直到我在验证访问令牌时遇到一个
facebook OAuthException
(OAuthException)错误。
错误,我无法捕获该异常,它导致我的应用程序崩溃

我正在使用这个调用
FacebookApp.apianc(“/me/feed”,…)
。因为它是异步发生的,所以我不确定必须将try-catch块放在何处才能捕获该错误,但没有成功

这就是我正在使用的:

    private void shareFBButton_Click(object sender, System.Windows.RoutedEventArgs e)
    {
        // ... code for preparing strings to post ...

        try
        {
            // setup FacebookApp and params ...
            
            app.ApiAsync("/me/feed", args, HttpMethod.Post, (o) => {
                if (o.Error != null)
                {
                    Debug.WriteLine("ERROR sharing on Facebook: " + o.Error.Message);
                }
                else
                {
                    Debug.WriteLine("FB post success!");
                }
            }, null);
        }
        catch (Exception ex)
        {
            Debug.WriteLine("ERROR sharing on Facebook: " + ex.Message);
        }    
    }
有人能告诉我应该把try-catch块放在哪里,这样我就可以捕捉到
OAuthException

编辑:

经过进一步调查,在SDK捕获WebException和FacebookApiException后,FaceBookOAutheXpetion从FacebookC#SDK中抛出。有关更多信息,请参阅“Pavel Surmenok”的答案。这正是正在发生的事情


到目前为止,捕获FacebookApiException(所有Facebook SDK异常的基类)的唯一解决方案是在App.UnhandledException方法中捕获它。检查e.ExceptionObject的类型,如果它是FacebookApiException,则将e.Handled设置为true,应用程序将不再自动退出。

调试器通常能很好地指示异常的来源。在调试器中,您可以检查异常详细信息并查看nessted InnerExceptions以查找根本原因

也就是说,如果异常是从app.apisync调用中抛出的,那么您已经拥有的catch处理程序将捕获任何异常。从SDK中的情况来看(我只是简单地看了一下),在某些情况下,异常会被捕获并转发到Error属性中的回调,您也在检查

通过查看SDK代码,看起来抛出的异常实际上是FaceBookOAutheException;是这样吗?如果是这种情况,那么看起来这个异常永远不会提供给回调,而是总是抛出


如果您能提供更多关于异常类型的详细信息以及抛出/捕获异常的位置,我可能会给出更有用的答案。

我找到了解决问题的方法。也许我应该重新表述我的问题

“如何捕获后台线程上发生的异常?”

这正是我最初的问题所发生的。由于Api调用是异步执行的,因此在后台线程的Facebook C#SDK中会抛出一个异常

也许你们中的大多数人已经知道这一点,但我不知道,因为我是WP7开发的新手

解决方案:

在App.UnhandledException事件处理程序中,只需将e.Handled标志设置为true。那么应用程序将不会自行退出

    private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
    {
        // catch Facebook API exceptions
        // if handled is set to true, app won't exit
        if (e.ExceptionObject is FacebookApiException) 
        {
            e.Handled = true;
            // notify user of error ...
            return;
        }

        if (System.Diagnostics.Debugger.IsAttached)
        {
            // An unhandled exception has occurred; break into the debugger
            System.Diagnostics.Debugger.Break();
        }            
    }

不确定这是否是捕获API异常的正确方法,但目前效果良好。

我重现了这个问题。如我所见,异常是在FacebookApp.ResponseCallback方法中生成的。它包含“try”块和两个“catch”部分(一个用于FacebookApiException,一个用于WebException)。在每个“捕获”部分的末尾,异常被重新调用,并且从未被处理过(这就是你的应用程序崩溃的原因)。因此,调试器会告诉您这个(重新启动)异常。 在后面的“最终”部分中,他们在属性“Error”中引用此异常创建FacebookAsyncResult。 我认为您的解决方案(在App.UnhandledException中处理此异常)是最合适的。
顺便说一句,很有趣的是,为什么SDK开发人员决定在FacebookApp.ResponseCallback中重新显示异常。

尝试在App.UnhandledException中捕获异常,因为它位于不同的线程上。但是,在执行查询之前,可以使用authResult中的“error-reason”属性,这样可以避免引发异常

private void FacebookLoginBrowser_Navigated(object sender, System.Windows.Navigation.NavigationEventArgs e)
    {
        FacebookAuthenticationResult authResult;
        if (FacebookAuthenticationResult.TryParse(e.Uri, out authResult))
        {
            if (authResult.ErrorReason == "user_denied")
            {
                // do something.
            }
            else
            {
                fbApp.Session = authResult.ToSession();
                loginSucceeded(); 
            }                
        }

您目前如何确定它是一个
OAutheException
?当您收到此错误时,您计划做什么?因为调试器说这是一个FacebookOAuthException,并且在
o.error.Message
I'm get”(OAuthException)error validating access token.”中调试器在哪里中断?你为什么不把它破坏的地方包装一下呢?只是下载了源代码并添加到我的项目中,看看异常到底是在哪里抛出的。它位于FacebookApp.cs:第883行。它抛出了一个FaceBookAPI异常。那么它不是FaceBookOAutheException?抛出的异常的详细信息是什么(消息和错误类型)?您现有的catch处理程序是否处理此异常?FacebookApiException是FaceBookOAutheException的基类。如果您最初提出的问题没有反映实际问题,请对其进行编辑,而不是添加扩展到原始问题的答案。如果OAuth失败,你不需要处理这个问题,以便让用户提供不同的凭据,而不是处理未处理的异常并继续吗?@Derek:是的。但是为了做到这一点,我必须首先捕获抛出的异常。现在看来,应用程序UnhandledException是唯一可以捕获该异常的地方。正如Matt在上面所问的,当抛出异常时,调试器在哪里中断?您应该能够将此点包装在托盘/捕捉块中以捕捉此异常。是的,这正是发生的情况。我还想知道为什么SDK开发人员决定重新引用捕获的异常。有什么好的解释吗?鉴于您可以访问源代码,我个人倾向于更改SDK,这样它就不会重新显示异常,因为异常详细信息在
facebooksyncResult
中提供。这是一个比在应用程序级未处理异常处理程序中处理要好得多的解决方案。但我会等待SDK的开发团队来完成,所以我不会浪费时间