-
Notifications
You must be signed in to change notification settings - Fork 315
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
Uncaught NumberFormatException when comparing (large) integers #1126
Comments
gouttegd
added a commit
to gouttegd/owlapi
that referenced
this issue
Feb 22, 2024
When comparing integer literal values, if the value we must compare to is not a OWLLiteralImplInteger, the call to parseInteger could raise a NumberFormatException if the value is too large to fit into a 32-bit integer. This commit catches this possible exception and falls back to comparing the integer based on their string literal representations. closes owlcs#1126
Looks like there's also some funny business in the literal parsing, as the value for owl:hasValue does not have a specified datatype and so shouldn't have been parsed to an integer literal. |
ignazio1977
pushed a commit
that referenced
this issue
Mar 10, 2024
When comparing integer literal values, if the value we must compare to is not a OWLLiteralImplInteger, the call to parseInteger could raise a NumberFormatException if the value is too large to fit into a 32-bit integer. This commit catches this possible exception and falls back to comparing the integer based on their string literal representations. closes #1126
ignazio1977
added a commit
that referenced
this issue
Sep 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue was initially reported on the Protégé bug tracker.
Protégé encounters an uncaught
NumberFormatException
in the OWL API when trying to display thehttp://www.semanticweb.org/ReproduceError/Testing/SuperClass1#subclass
class from the ontology in the attached file:ReproduceErrorNumberFormatException2.txt
This is because of the large integer value 92740100783 in one of the class expressions defining the class.
In code, the easiest way to reproduce the bug is (assuming
df
is anOWLDataFactory
):The
compareTo
call raises aNumberFormatException
. I believe the issues lies in the equals(OWLObject) method of theOWLLiteralImplInteger
class:because the call to
parseInteger()
is not protected. Ifobj
happens to be an instance ofOWLLiteralImplNoCompression
containing the string representation of a large integer, that call will raise theNumberFormatException
.The text was updated successfully, but these errors were encountered: