Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suppressing exception thrown when accessing HttpContext.Request #56

Merged
merged 4 commits into from
May 12, 2016
Merged

Suppressing exception thrown when accessing HttpContext.Request #56

merged 4 commits into from
May 12, 2016

Conversation

vegar
Copy link
Contributor

@vegar vegar commented May 11, 2016

As a response to #31

I have not kept the old behavior for .net core.

}
catch (HttpException)
{
return null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least a InternalLogger.debug(ex) can be added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The compiler refuses to accept InternalLogger.Debug(ex). It will only accept two variants of the Debug method: One taking a string, and the other taking a string and a argument array. Is that as excepted?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes that's is added to NLog 4.3.

Debug(Ex.tostring()) is preferred.

Copy link
Contributor Author

@vegar vegar May 11, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 With or without any further explanation?

InternalLogger.Debug("Exception thrown when accessing Request: " + ex);
or
InternalLogger.Debug(ex.ToString());

Do you want a separate test verifying that it is logged?

Current test passes based on the default log level for the internal logger discarding debug statements. A separate test can be added to verify that the internal logger do pick up on the exception if log level is set appropriately.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first please :)

No need for testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOL,

is this a response on "no need for testing"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I was taken by surprise. It's not the response I'm used to ;-)

@304NotModified
Copy link
Member

Thanks!

@304NotModified
Copy link
Member

coreclr build is a "bit" broken now ;)

@vegar
Copy link
Contributor Author

vegar commented May 12, 2016

I guess it's time to start looking into this .net core thing then...

@vegar
Copy link
Contributor Author

vegar commented May 12, 2016

Is there a reason why the IHttpContextAccessor that is implemented inside of NLog.Web returns a HttpContextBase while the IHttpContextAccessor coming with .net core returns a HttpContext ?

@304NotModified
Copy link
Member

s there a reason why the IHttpContextAccessor that is implemented inside of NLog.Web returns a HttpContextBase while the IHttpContextAccessor coming with .net core returns a HttpContext ?

AFAIK we need the HttpRequestBase in ASP.NET 4 (note: HttpRequest won't inherit from HttpRequestBase !) and there is no HttpRequestBase in .NET CORE

@304NotModified 304NotModified merged commit 6a1e79e into NLog:master May 12, 2016
@vegar vegar deleted the CatchRequest branch May 12, 2016 22:00
@vegar
Copy link
Contributor Author

vegar commented May 12, 2016

Ok. Glad you could use the code. Hopefully, we can delete our own implementations pretty soon :-)

Keep up the good work.

@s-sreenath
Copy link
Contributor

I have question about this PR. Wouldn't we want to implement the same TryGet Method for where we have access the Request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants