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

LANG-1720: Fix Javadoc description of exceptions thrown for Conversion class #1139

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

arthurscchan
Copy link
Contributor

@arthurscchan arthurscchan commented Nov 27, 2023

The Javadoc comments for most methods of the Conversion class contain detailed descriptions of the reason for some expected exceptions thrown. These exceptions include but are not limited to different IndexOutOfBoundsException or NullPointerException. It is found that all variants of the hexTo*() method will throw StringIndexOutOfBoundsException if srcPos + nHex > src.length but this is not documented. Thus this PR provides an improvement of the relative Javadoc, mentioning that these methods could throw StringIndexOutOfBoundsException.

@codecov-commenter
Copy link

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (c52fec6) 92.14% compared to head (8043291) 92.15%.
Report is 8 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1139      +/-   ##
============================================
+ Coverage     92.14%   92.15%   +0.01%     
- Complexity     7595     7596       +1     
============================================
  Files           200      200              
  Lines         15910    15910              
  Branches       2925     2925              
============================================
+ Hits          14660    14662       +2     
+ Misses          676      675       -1     
+ Partials        574      573       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@garydgregory
Copy link
Member

@arthurscchan
I'm not so sure about this one. Maybe the original runtime exception should be rethrown as an IllegalArgumentException.

@arthurscchan
Copy link
Contributor Author

arthurscchan commented Dec 7, 2023

I am ok with either way. But it may need to change other methods to remain consistency. For example, the other method here, just throw IndexOutOfBoundsException directly and document that. @garydgregory

@elharo
Copy link
Contributor

elharo commented Jan 3, 2024

I agree with @garydgregory Throwing IndexOutOfBoundsExceptions from these methods is a bug. These should all be IllegalArgumentException. Filed https://issues.apache.org/jira/browse/LANG-1725

@michael-o
Copy link
Member

I agree with @garydgregory Throwing IndexOutOfBoundsExceptions from these methods i a bug. These should all be IllegalArgumentException. Filed https://issues.apache.org/jira/browse/LANG-1725

Agree as well.

@elharo
Copy link
Contributor

elharo commented Jan 3, 2024

Given that we do want to change this behavior, it's probably not a good idea to Javadoc the current behavior, so I suggest closing this PR. However, it is still very valuable for calling our attention to this issue. Thanks.

@garydgregory
Copy link
Member

I agree this PR should be closed as is. I'll leave it open for now if @arthurscchan wants to update it with code changes instead.

@elharo
Copy link
Contributor

elharo commented Jan 9, 2024

On further investigation, I'm not so sure. The API here is really strange. Since the indexes that can be out of bounds are passed in from client code, StringIndexOutOfBoundsException seems appropriate in at least some cases.

@garydgregory
Copy link
Member

@elharo and all
Taking the same approach as java.util.Arrays seems reasonable but that class checks and throws exceptions (IAE and ArrayIndexOutOfBoundsException) explicitly instead of letting code fail. Thoughts?

@elharo
Copy link
Contributor

elharo commented Jan 10, 2024

Letting code fail is fine and avoids extra work on the happy path. If an explicit check isn't needed, it isn't needed. The important thing is to document and test the desired behavior. As long as the behavior is tested, how the behavior is implemented is a detail.

@garydgregory
Copy link
Member

It sounds like we are ok with this PR then. @elharo @michael-o ?

Copy link
Contributor

@elharo elharo left a comment

Choose a reason for hiding this comment

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

TBH I'm not sure I like this class or its API at all. I still don't feel like I understand it, but if it exists it should be properly documented and this PR helps with that.

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.

5 participants