Closed blake-regalia closed 6 years ago
Not sure I agree. BAD_CURIE curie implies a syntax error and is used when reading, so this is the error you will get if you try to parse a file that contains a bad CURIE.
For using the env API directly, it would be a bit weird for it to return BAD_CURIE if the string itself is a perfectly good curie (and not, say, missing a colon) but the prefix just isn't in the env.
Perhaps "prefix does not exist" should be its own error to distinguish a syntactically invalid CURIE from an undefined prefix in both places?
Just to be clear, I am saying that the documentation is unclear in this regard. Namely, that BAD_CURE literally says "prefix does not exist" in the docs. Not sure what you mean by "not agree" since I am only pointing out the confusion from a user's perspective.
I meant agree with your expectation that serd_env_expand
would return something else. This is a context problem, the errors were written for a reading and writing perspective (it's relatively uncommon to use this part of the API directly in application code).
I guess I could either simply remove the "prefix does not exist" from that comment, or make serd_env_expand
return it in the not found case (which would make SERD_ERR_NOT_FOUND
unused, but oh well), and stick with SERD_ERR_BAD_ARG
if the input isn't a CURIE at all?
serd_env_expand
will returnSERD_ERR_NOT_FOUND
if the prefix does not exist / was not found, and yet the enum doc forSERD_ERR_BAD_CURIE
says: "Invalid CURIE (e.g. prefix does not exist)". Not a huge deal, but a bit redundant/confusing? Just intuitively, after the reading the docs, I would expectserd_env_expand
to return the 'bad curie' enum value instead of the 'not found' one.