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
gen_server types (OTP-17915) #5751
gen_server types (OTP-17915) #5751
Conversation
CT Test Results 4 files 159 suites 1h 27m 47s ⏱️ For more details on these failures, see this check. Results for commit 95f0ec3. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
This pull request causes the |
To facilitate documentation review, here are some links of what I feel would be worth looking at:
And, of course, If anyone would proofread the whole new |
Since there now are type specs I have moved the explanation of of the type values to the type. Previously the it had to be under a selected function and then other functions referred to that function. Now all functions refer to the type. For example; under the type start_ret() the possible return values for all start functions (start/3,4, start_link/3,4 and start_monitor/3,4) are described and all start functions refer to start_ret(). Previously the return values were described under start_link/3,4 and the other start functions referred to it. Now you often need to follow a link to find the explanation of a value, but it is described together with the auto generated type spec so it is less likely that the description starts diverting from the type spec, and the description can refer to annotation variables in the spec. In short, information duplication has been reduced by moving the information to a type, but that requires the reader to follow a link to find the information from a function description.
e97026b
to
76bed16
Compare
In the documentation of the function gen_server:call it says:
I never liked this wording. I think "the function call fails" is too vague and it is not obvious what is meant by that. I think it would be clearer to say the function calls fails by exiting the process that is calling the function, and if the process catches this exit and continues to run it must be prepared to receive a late answer, as the server is not affected by the client timeout. This should be done by disregarding any such late messages that are two-element tuples with a reference as the first element. Also, I think it would be an improvement if we could make an exit type for the most common exit reasons instead of just saying "The call can fail for many reasons, including time-out and the called gen_server process dying before or during the call." |
Also, enter_loop could specify its failing by exiting better. |
That is discussed in PR #5683. I think we should handle it there. |
Does it really merit a type of its own? |
Sure, you will be the driver either way ;) |
Humm ... maybe, maybe not (it is not a return-type after all). Make a suggestion and we can take it from there. |
ee30150
to
5e3e003
Compare
The `gen` module raises `exit` exceptions when it detects an error. Clean up handling of these by not handling other classes of errors, to not accidentally bury an interesting cannot-happen-error.
5e3e003
to
95f0ec3
Compare
This pull request exports
gen_server
types as suggested in PR #2375 and PR #2690, fixes a few type violations now found in Kernel, updates the documentation to utilize the type specs, and hopefully gets all type details right, at least after a few rounds of review...Is this the right set of types to export from
gen_server
?Are the right types opaque in the right way?
Is the documentation update an improvement?
Are there any obvious things to fix in the documentation while at it?