-
-
Notifications
You must be signed in to change notification settings - Fork 836
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
In-progress links in exception messages (plus misc exception msg improvements) #1281
In-progress links in exception messages (plus misc exception msg improvements) #1281
Conversation
…ge if we're using the default binder
Looking good! I think this will help a lot to reduce the "I didn't read the exception message" questions on SO. Maybe. 🤔 If the exception doc is going to show up in the table of contents on the doc site it might need either:
That way if we handle more exception types we can organize by type. |
Might have to end up with a doc per-error; redirects don't seem to like anchor tags very much. If so, probably a section per exception type, then divided again by error. |
Codecov ReportBase: 77.98% // Head: 77.97% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## develop #1281 +/- ##
===========================================
- Coverage 77.98% 77.97% -0.02%
===========================================
Files 195 195
Lines 5587 5593 +6
Branches 1119 1120 +1
===========================================
+ Hits 4357 4361 +4
- Misses 716 717 +1
- Partials 514 515 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
This appears to have gotten pretty stale. I think it's still interesting to finish, though. Is there something I can do to help get it out the door? If we need one-doc-per-error I may be able to start that, possibly under the "Troubleshooting" section. I can use the changes here as a guide for which exceptions need a doc unless you have a list. |
Yeah, apologies for letting this stagnate so long, lost impetus on it for some reason. Basically, the mechanic is all there, so all that needs doing is the documentation pages, and then updating the messages with the links. That |
I think what I'll do first is try to update the doc site so we have a more robust troubleshooting section that will eventually house specific exception docs underneath. Since the redirects don't like After that we can figure out what to do about the code. It looks like it's in your fork rather than a branch right in this repo, which is fine, but means I can't easily pick it up and run with it. Not a huge deal, doesn't look like too much has changed here so applying the diff to a new branch I can access should be easy enough. Once I get some momentum here, we can close this PR. |
I think I have the |
Is it easier if I retarget this PR to a feature branch in the Autofac repo rather than develop, and you can then base on that? I'll merge latest develop in here anyway. |
# Conflicts: # src/Autofac/Core/Activators/Reflection/ReflectionActivator.cs # test/Autofac.Test/Core/Activators/Reflection/ReflectionActivatorTests.cs # test/Autofac.Test/Factory.cs
OK, this is up-to-date with develop now. You want to update the PR to point at a new local repo branch off develop? |
Actually, yeah, then I can just pick up where you left off. That'd be awesome. |
OK, these changes are now in |
Trying out links in the exception messages to see if people are happy with the approach.
See https://autofac.readthedocs.io/en/exception-docs/faq/exception-info.html for a (hidden) branch of documentation that contains the linked content (branch is at https://github.com/autofac/Documentation/tree/exception-docs).
Redirects are set up using readthedocs built-in redirect behaviour, to give us a shorter link for the full one that includes an anchor tag:
So, visiting https://autofac.rtfd.io/help/no-constructors-bindable (in the exception message) will go through the redirect and end up at the right place.
I've also simplified the "NoConstructorsBindable" message to show a simpler message if they are using the DefaultConstructorFinder (99.99% of cases I'd imagine), just to reduce potential confusion.