Problem/Motivation
There are few functions which are missing @throws tags in docblock
Currently i'm working on fixing it in /core/modules folder
Proposed resolution
Patch documentation.
Remaining tasks
1. Make a patch (done).
2. Good NOVICE TASK (or anyone) Do a careful review of the patch. Someone needs to check the code for each method/function with new or updated @throws documentation, and verify in each case that:
a) The exception class that is in the @throws documentation is actually, directly thrown by the function/method (i.e., there is a throw statement in the method that throws an exception of the documented class). We do not document exceptions thrown by functions/methods that are called by this method, only ones directly thrown. Note that if the @throws documentation is on an interface method, you'll need to look at implementing classes to see the code.
b) If there is documentation about when/why the exception is thrown, it matches the logic in the function/method for throwing this exception.
User interface changes
No.
API changes
No.
Data model changes
No.
| Comment | File | Size | Author |
|---|---|---|---|
| #83 | interdiff-80-83.txt | 30.29 KB | rang501 |
| #83 | comment-standards-2595999-83.patch | 18.5 KB | rang501 |
| #80 | comment-standards-2595999-80.patch | 18.59 KB | hussainweb |
| #77 | interdiff-2595999-72-75.txt | 8.96 KB | anil.gangwal |
| #77 | comment-standards-2595999-75.patch | 18.54 KB | anil.gangwal |
Comments
Comment #2
krknth commentedpatch attached.
review required
Comment #3
krknth commentedComment #4
jhodgdonHm. We only want @throws to be on a method/function if the method/function *directly* throws that exception. I do not have time to look through this in detail right now, but ... do all of these functions directly throw exceptions, or are you attempting to document exceptions that they might not catch that come from other classes/methods deeper in the code?
Comment #5
krknth commented@jhodgdon : Yes, I'm attempting to document exceptions. Because there are many functions already used @throws tag even functions are not throwing exceptions directly.
Comment #6
krknth commentedComment #7
jhodgdonThe @throws tag should *only* be used on the function that throws the exception directly. If it is being used otherwise, it should be removed from the other functions.
Comment #8
krknth commentedLooking into @jhodgdon comment
Comment #9
rakesh.gectcrComment #10
rakesh.gectcr@jhodgdon
Correct me if i am wrong , What i understand from throws the exception directly.
It should not be used in the try -catch.
It should be thrown directly, like
In that case. I have cleaned it. Please review the attached patch.
Comment #11
rakesh.gectcrComment #12
jhodgdonThanks! I didn't check over whether the @throws were correct (that is very time consuming), but I have a few comments on the docs and formatting and stuff like that:
Normally we want @throws after @return.
See
https://www.drupal.org/node/1354#order
It seems like this @throws might need some documentation? The name "FieldException" is kind of generic. Our standards suggest adding docs if the name of the exception class doesn't tell you immediately why this would be thrown, and I think this is one of those cases.
Same here, and for the other FieldException throws.
Move to after @return... not going to mark the rest of the patch but they need to be done too.
OK here for sure we need to know why it would throw an exception!
needs docs
needs docs
needs docs
needs docs
OK I'm not going to mark the rest of these but ...
This needs a full namespace
Um. AccessDenied when the view is not found??? I doubt it.
Comment #13
rakesh.gectcr@jhodgdon
I am working it, will update you soon
Comment #14
rakesh.gectcr@jhodgdon
I have fixed all those points you mentioned
Comment #15
rakesh.gectcrComment #16
jhodgdonRE #14 - please provide an interdiff file. This is essential on a patch of this size when you make a new patch. Thanks!
See
https://www.drupal.org/documentation/git/interdiff
Comment #17
rakesh.gectcr@jhodgdon
Please find the attached
interdifffile between the patches2595999-2.patch and 2595999-3.patchComment #18
jhodgdonI reviewed the interdiff file -- much improved, thanks!
A few smaller things to fix:
ids => IDs
This is a bit garbled? Not sure what it means.
These are all throwing the same exception. So I think we only want one @throws, and then the explanation can be something like:
Thrown when the ..., ..., ..., ..., or ....
Same here.
Do you think we want an explanation of what type of unexpected value this would be?
Combine into one @throws
Combine into one @throws
are => have
ajax => Ajax
ajax => Ajax
Combine into one @throws
Also grammar:
"is no begin" => "does not begin"
I think this could use an explanation doc
Needs explanation
Needs explanation
Needs explanation
Actually you changed the meaning here. It previously said it was thrown when the *display* ID wasn't found, and now it says the view ID. Please verify.
id => ID
Comment #19
rakesh.gectcr@jhodgdon
I have done the changes which you mentioned. Please find the attached patch and interdiff files.
About the point 16, you are right , I changed it again, the following code is the condition
So changed the explanation to
Comment #20
rakesh.gectcrComment #21
jhodgdonAbout point 16, it looks like it is thrown if either the view isn't found, or the access check fails? I don't think I would say the access is "not found", when what is happening is that the access check says "you don't have permission", right?
Some other notes -- again I reviewed the interdiff -- which mostly looks very good!
In Drupal docs, our style guide says we need to use serial commas.
So we need a comma before the "or" in the last line:
... no field name, entity type, or bundle ...
... options are already exists... => ... options already exist ...
Um. I think curl should be cURL? I am not sure, please verify the correct capitalization.
The key is not aquiring a lock..
Maybe say this:
Thrown when a lock cannot be acquired.
same here
see earlier note about point 16.
Thanks!
Comment #22
rakesh.gectcr@jhodgdon
I have done the changes you mentioned. Please find the attached files.
Thank You
Comment #23
rakesh.gectcrComment #24
jhodgdonAlmost!
exists -> exist
was removing this from the patch here intentional?
So... I have been reviewing the Interdiff files.
We need to find someone to check over the entire patch and make sure the @throws documentation is accurate. This will take some time, and right now I don't have the time to spend on it, sorry!
Maybe you can ask in IRC, especially at the next mentoring hours?
Comment #25
jhodgdonAdding explanation of the review that is needed to the issue summary.
Comment #26
jhodgdonMarking the review as a good Novice task
Comment #27
snehi commentedThanks for the patch.
Meanwhile done with #24
Comment #29
rakesh.gectcrComment #30
rakesh.gectcr@jhodgdon
I have done the changes , 2nd point was fully unintentional.
I have added the patch that and interdiff,
@snehi
thanks for the patch. Please check the way we use to name the files. Please follow that only here . So that it will clear the confusions.
Comment #31
rakesh.gectcrComment #38
snehi commentedAre you talking about interdiff files ?
Comment #39
rakesh.gectcrComment #40
rakesh.gectcrComment #47
rakesh.gectcrComment #48
rakesh.gectcrComment #57
sdstyles commentedRerolled #47, changed core/modules/views/src/ViewExecutable.php to apply patch correctly.
Comment #58
rakesh.gectcr@sdstyles
Can you please upload the interdiff file also
Comment #59
rakesh.gectcrComment #60
rakesh.gectcrComment #61
jhodgdonThanks for the patches and interdiffs!
So I went through the latest patch. Again, I have not checked the *accuracy* of the @throws documentation, which is still a Remaining Task that someone needs to do.
But I am still finding some clarity problems:
What does "the requested object" mean here? Needs better docs, more specific.
When using a class name in docs, include the full namespace starting with \
These are all the same exception. Combine them into one @throws please.
This needs docs about when/why it is thrown.
This needs docs about when/why it is thrown.
Needs docs.
Comment #62
rakesh.gectcr@jhodgdon,
I have done the changes.
Comment #63
jhodgdonThanks! Looking better.
There are still some clarity/typo things to clear up. And someone still needs to review this, as outlined in the issue summary, for accuracy (which I have not done).
Not sure what this means. I think it means that the reqested filter object doesn't exist? Anyway, needs to be clarified.
When using a class/interface in docs, provide the full namespace.
there is special characters => there are special characters
should not be a comma in here
Should not be a comma here
shouldn't this be handler's rather than handlers? I think we're talking about the URL of the handler, but not sure. I would also probably word this as:
An object representing the URL of the display.
(assuming that this is correct)
Comment #64
priya.chat commentedHello @jhodgdon,
I picked up @rakesh.gectcr last patch and done some of the points you mentioned in your last review comment.
I am not sure about points 1,2 so I picked up 3,4 & 5.
In my patch , there are some improvements that been done like :
For point 3
For point 4
For point 5
For point 6
Please review the above points.
Comment #65
rakesh.gectcr@priya.chat
good work,
Please check how to name the interdiff files
Comment #66
heykarthikwithu@priya.chat, mentioned few changes.
+ * @throws \Drupal\Core\Entity\Exception\FieldStorageDefinitionUpdateForbiddenExceptionShould have some documentation about the exception.
Comment #67
rakesh.gectcrComment #68
kaushalkishorejaiswal commentedHello heykarthikwithu,
I have made the changes in the comments kindly look into it.
Comment #69
rakesh.gectcr@kaushalkishorejaiswal
Thanks for the patch, Can you please add the interdiff file of patches Comment #62,#64 and #68.
Seee :- https://www.drupal.org/documentation/git/interdiff
Comment #70
kaushalkishorejaiswal commentedHello Rakesh,
Kindly find the interdiff file. I appreciate your knowledge sharing.
Comment #71
heykarthikwithuShould have spaces.
Similarly in few more places.
Comment #72
r_sharma08 commented#71:patch applied, please review
Comment #73
r_sharma08 commentedComment #74
jhodgdonThanks for the patches! Sorry for the delay in reviewing -- I've been on vacation and no one else, unfortunately, ever reviews docs patches. :(
Since it's been so long, I just started by looking at the patch in #72, and did not review the interdiffs...
So I started to look through these, and found that the @throws documentation left me with a lot of questions. I got through about half of the patch and made these notes, and didn't review the whole patch, but you'll get the idea... If we're going to document these things, we need to have the documentation make sense.
I don't understand what this line means at all.
Hm. This is in the docs header for a hook... so... Are you saying that the hook implementation should throw this exception if it wants to forbid something? If so, it should be phrased that way. If not, I don't get this statement at all.
Um, what does this mean? This is the docs for field_purge_field_storage(). Are you saying that the storage cannot be purged if it has fields? Then what is the use of purging it?
What given field storage? The only args here are $values and $entity_type.
Where are these things found? The only args here are $values and an entity type.
Not sure what this means, found where?
These two do not conform to our standards of how to document this.
Doesn't match the pattern of the others, and there is an extra space at the end of the first docs line, and the second one isn't indented.
Associated with what?
Comment #75
anil.gangwal commentedChanges applied. Please review.
Comment #77
anil.gangwal commentedPlease review.
Comment #78
anil.gangwal commentedComment #80
hussainwebRerolling/fixing the patch in #75.
Comment #81
jhodgdonThanks for the rerolls... The patch still needs considerable work though. The main problem is that the English grammar and spelling in the exception explanations needs some attention:
needs "is" in here.
The grammar here is garbled.
When mentioning a class/interface in API documentation, always include the namespace.
Several spelling errors here.
Also... this reads funny. I don't think we need "special" in the line at all, since it goes on to say what characters are allowed?
grammar attention needed (needs a/an/the)
needs a verb
grammar a/an/the needed and no verb
bad grammar
no verb
no verb
needs 2 spaces of indentation
But ... duh. This line does not tell me anything that the name of the exception doesn't tell me.
It should say:
Thrown when ....
or be omitted.
See comment above on the UnsupportedMediaType exception.
Huh? What does this mean?
Comment #82
snehi commentedComment #83
rang501 commentedHi!
I tried to fix the mentioned problems.
Clarification about points 11 and 12 - for the first one, I added a better comment, for the second one I removed the comment (unable to add a logical explanation for that one).
About the point 13 - I think this @return is out of scope, so removed that one.
I did a quick review on other changes, found one possible problem:
This seems to be weird, am I right?
Comment #84
jhodgdonI'm sorry, but this issue is now violating our issue scope guidelines for this type of coding standards cleanup. See
https://www.drupal.org/core/scope
So. The issue needs rescoping before we can proceed. See that document for more information. Until this is done, and the issue is properly scoped, I'm not going to spend time reviewing it, because in the end the core committers will not commit patches any more on issues that are improperly scoped.
Thanks!
Comment #85
rang501 commentedHi!
Who can do the rescoping?
If I understand correctly, this issue address only missing @throws tags. This should be a good scope according to this table (last example) https://www.drupal.org/core/scope#examples
Comment #86
jhodgdonYes, just doing @throws is good.
The scoping problem is that this issue/patch just addresses some subset of Drupal Core for @throws. It needs to be part of a "meta" issue with a plan for addressing all of Drupal Core, which needs to be a child issue of the main "Fix coding standards" issue. And it probably will need some kind of a coder sniffer thing. See the scoping document for more details.
What we're trying to avoid is having one-off patches like this issue, which address a coding standards issue without a coder sniffer rule and without covering all of Core or having a plan to do so.
Thanks!
Comment #95
quietone commentedYes, coding standards are done by sniff. This no longer needs an issue re-scope, so removing tag. Adding tags for coding standards and Bug Smash (one of the reasons I found this issue). Changing to a Task in accordance with coding standards issues.
Some of the fixes in the patch are still relevant.
Postponing this until there is a sniff for the @throws.
Comment #96
quietone commentedShould have changed the version.