locked
Blazor Wasm Exception Messages Need Line Number References RRS feed

  • Question

  • User-343630552 posted

    I am developing a Blazor Wasm app in Visual Studio Community 2019.  I know it just released in May, so I'm not surprised there are some things that need improvement.  One that I'm finding is that the exception messages that are logged on certain types of exceptions don't say anything about where the exception occurred.  See an example below.  Am I missing something?  Is this the kind of thing that needs to be put on a development list?  Thanks.  Steve

    crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
    Unhandled exception rendering component: Object reference not set to an instance of an object.
    System.NullReferenceException: Object reference not set to an instance of an object.
    at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
    at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) <0x263e320 + 0x000ce> in <filename unknown>:0
    --- End of stack trace from previous location where exception was thrown ---

    at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion (System.Threading.Tasks.Task task) <0x302d8b8 + 0x000da> in <filename unknown>:0
    at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask (System.Threading.Tasks.Task taskToHandle) <0x2d35e78 + 0x000b6> in <filename unknown>:0
    f.printErr @ blazor.webassembly.js:1
    f.preRun.push.window.Blazor._internal.dotNetCriticalError @ blazor.webassembly.js:1
    _mono_wasm_invoke_js_unmarshalled @ dotnet.3.2.0.js:1
    do_icall @ dotnet.wasm:1
    do_icall_wrapper @ dotnet.wasm:1
    interp_exec_method @ dotnet.wasm:1
    interp_runtime_invoke @ dotnet.wasm:1
    mono_jit_runtime_invoke @ dotnet.wasm:1
    do_runtime_invoke @ dotnet.wasm:1
    mono_runtime_invoke_checked @ dotnet.wasm:1
    mono_runtime_try_invoke_array @ dotnet.wasm:1
    ves_icall_InternalInvoke @ dotnet.wasm:1
    ves_icall_InternalInvoke_raw @ dotnet.wasm:1
    do_icall @ dotnet.wasm:1
    do_icall_wrapper @ dotnet.wasm:1
    interp_exec_method @ dotnet.wasm:1
    interp_runtime_invoke @ dotnet.wasm:1
    mono_jit_runtime_invoke @ dotnet.wasm:1
    do_runtime_invoke @ dotnet.wasm:1
    mono_runtime_try_invoke @ dotnet.wasm:1
    mono_runtime_invoke @ dotnet.wasm:1
    mono_wasm_invoke_method @ dotnet.wasm:1
    Module._mono_wasm_invoke_method @ dotnet.3.2.0.js:1
    call_method @ dotnet.3.2.0.js:1
    (anonymous) @ dotnet.3.2.0.js:1
    beginInvokeDotNetFromJS @ blazor.webassembly.js:1
    s @ blazor.webassembly.js:1
    e.invokeMethodAsync @ blazor.webassembly.js:1
    (anonymous) @ blazor.webassembly.js:1
    t.dispatchEvent @ blazor.webassembly.js:1
    (anonymous) @ blazor.webassembly.js:1
    (anonymous) @ blazor.webassembly.js:1
    e.onGlobalEvent @ blazor.webassembly.js:1
    Show 3 more frames

    Wednesday, July 15, 2020 2:56 PM

Answers

All replies

  • User-257536521 posted

    So that we can properly investigate this issue, could you please open a GitHub issue in the https://github.com/dotnet/aspnetcore/issues repo with detailed steps on how to reproduce the problem? Thank you!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, July 15, 2020 10:28 PM
  • User-343630552 posted

    Thanks, Dan.  I have opened the GitHub issue.

    Thursday, July 16, 2020 3:33 PM