NavigationException doesn't have a useful message.

[danmoseley]

this

aspnetcore/src/Components/Server/src/Circuits/RemoteNavigationManager.cs

Line 91 in d8a3aa8

throw new NavigationException(absoluteUriString);

creates an exception like this

with the URL in the Location field.

Ideally it should have a useful message that includes the URI, eg., "Could not navigate to https://localhost:7298/item/99"

the problem is that NavigationException is not overriding Message and ToString

aspnetcore/src/Components/Components/src/NavigationException.cs

Line 9 in d8a3aa8

public class NavigationException : Exception

If we want to keep the URL out of the message for security reasons, it should at least have a message like "Could not navigate to the URL".

[danmoseley]

If we want to keep the URL out of the message for security reasons, it should at least have a message like "Could not navigate to the URL".

@blowdart what is our policy for what can go into exception messages out of aspnet ? We disable display by default, of course. But these may go into logs. If we don't want the URL in the message, is it OK in the ToString()? (after all, it's in a property on the exception object)

[javiercn]

@danmoseley you are only probably seeing that because you have first chance exceptions turned on. The exception gets internally caught by the framework and handled. Is that not the case in your situation?

[blowdart]

I'm in conversations with other teams internally about logs and error messages, which may drive some requirements for 9

[mkArtakMSFT]

I'm following up with the Debugger team to see how we can ignore certain types of exceptions to avoid confusion here.

[danmoseley]

you have first chance exceptions turned on

Could well be. If it's always caught then it doesn't matter much. But first chance do still get logged in the debugger output - why not override Message.

It's possible you could ask the VS debugger team to buy default not catch this first chance. They seem to do this for certain exception types out of the box. (I'm assuming you can't avoid throw/catch here due to architecture)

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

After some further discussion in the team we're moving forward with the following:

1. Change the exception message to make it more user friendly
2. Follow up with the debugger team to see how to avoid treating these as first-chance exceptions.