Necessary Maintenance #8532

A question of the appropriate place for testing for the presence of a dictionary for a type of a product

Added by Christopher Green almost 6 years ago. Updated over 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
SSI Package:


Given a user requesting (e.g., via getByLabel()) a product for which there is no dictionary, but that product does not exist in the input file, should that be an immediate exception due to the missing dictionary, or a delayed exception due to the missing product?

There are tests that rely on the current behavior of the system, which is to delay the missing product exception and stay silent on the matter of the missing dictionary.


#1 Updated by Marc Paterno almost 6 years ago

My preference is (almost) always to report an error as soon as possible. In this case, that would seem to be link time. Is there a way we can make it a link error to use findByLabel (and other accessors of that ilk) for a type that does not have a dictionary?

#2 Updated by Christopher Green almost 6 years ago

The question is, whether it is an immediately-fatal error to request a product for which you do not have a dictionary even if that product is not present. Users are used to being able to do the getByLabel() call and have the opportunity to check the status of the handle in the case of a missing product: this would be a change to that behavior.

Even if we went with the earlier fail, I would not wish to force a link-time dependency, because that would have the effect of forcing the user to always have the data product definition code in a different library from the code making the getByLabel() call (to avoid a circular dependency), which I think is an unreasonable restriction on the user's flexibility to organize their code as they see fit.

#3 Updated by Kyle Knoepfel almost 6 years ago

  • Status changed from New to Feedback

We propose discussing this issue among stakeholders to determine which behavior is preferred.

#4 Updated by Kyle Knoepfel over 4 years ago

  • Status changed from Feedback to Rejected

Closed due to the rare combination of circumstances that would yield this kind of error.

Also available in: Atom PDF