Project

General

Profile

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 over 4 years ago. Updated about 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
04/29/2015
Due date:
% Done:

0%

Estimated time:
Scope:
Experiment:
SSI Package:
Duration:

Description

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.

History

#1 Updated by Marc Paterno over 4 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 over 4 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 over 4 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 about 3 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