Stream: shorthand
Topic: need better error than null object
John Moehrke (Nov 25 2020 at 15:55):
Please provide more information when this error is given. I am catching on that it is usually caused by a link to a missing object, but what link?
Sushi: error SUSHI encountered the following unexpected error: Cannot convert undefined or null to object (00:08.0208)
Chris Moesel (Nov 25 2020 at 16:42):
The problem is that this was an "unexpected" error, which usually means the error occurred in a low level of code, but we only caught it in higher-level error handling. This particular error message does not come from SUSHI code, so it probably comes from Node.js or one of our dependency libraries. So... we likely only have whatever information bubbled up with the error.
Chris Moesel (Nov 25 2020 at 16:44):
If you can identify a specific use case (or line of FSH) that causes this error, and/or if you can provide a stack trace for it, we can investigate and see if we can catch it in the deeper code and provide a more useful error message.
Elliot Silver (Nov 25 2020 at 16:46):
I think I see these errors most often on incorrect array indexes. (1, 2, 4,...)
John Moehrke (Nov 25 2020 at 17:10):
well, I am constantly confused by the array indexes... that is what I am tracking down now
Max Masnick (Nov 25 2020 at 17:55):
FWIW I had this exact same error yesterday related to me messing up array indices -- specifically trying to assign something[1] when something[0] didn't exist.
John Moehrke (Nov 25 2020 at 18:18):
yes, would be nice to catch these with more helpful error message.... why sometimes starts at zero and other times starts at one?
Elliot Silver (Nov 25 2020 at 18:37):
I think all indexes start at zero.
My problem is when moving things around I sometimes forget to renumber correctly. (It happens when you have an 80 element StructureDefinition with manually maintained numbering. )
John Moehrke (Nov 25 2020 at 18:43):
I am not sure it is that clear... the first one is not numbered, the second one is numbered 1... unless you number the first one, then you start at 1
Elliot Silver (Nov 25 2020 at 18:44):
I actually hadn’t realized that you don’t need to number the first one. Any time I have a repeating element, I start with index 0.
John Moehrke (Nov 25 2020 at 18:44):
then if you have slices,you must use the slice identifier... and then what numbers do you use after that?
Elliot Silver (Nov 25 2020 at 18:45):
Ooh, good question.
David Pyke (Nov 25 2020 at 18:51):
I didn't think it mattered as long as they were sequential. Is that not the case?
Max Masnick (Nov 25 2020 at 20:07):
I think the FSH team is considering a feature to dynamically assign indices rather than having to manually specify them, which would resolve this sort of problem
David Pyke (Nov 25 2020 at 21:01):
I thought that made it into V1.0? Oh well, good thing I didnt' test it
Chris Moesel (Nov 25 2020 at 21:09):
-
The soft-indexing feature that @Max Masnick referred to is in the works but is not yet released. As Max suggested, it will help w/ these issues a lot.
-
Indexes always start at
[0], but if you reference an array path and _don't_ include an index, then[0]is assumed. This is to make statements like*name.given = "Chris"less awkward (vs.* name[0].given[0] = "Chris") -
Slices do make this interesting for sure. If you have a slice that allows multiple cardinality, then you index into the slice's sub-section using indexes after the slicename. E.g.,
component[sliceA][0],component[sliceA][1],component[sliceB][0], etc. -
In the example above, if you also want to add items that don't fit into a defined slice (so you can't reference them by name), I think you probably have to do math and figure out the right index to use. Following from the example in (3) above, I think the next component is
component[3]. -
Thanks for hints regarding where to track down some of these unhelpful error messages. We'll see what we can do about that.
Elliot Silver (Nov 25 2020 at 22:08):
Chris Moesel said:
Slices do make this interesting for sure. If you have a slice that allows multiple cardinality, then you index into the slice's sub-section using indexes after the slicename. E.g.,
component[sliceA][0],component[sliceA][1],component[sliceB][0], etc.In the example above, if you also want to add items that don't fit into a defined slice (so you can't reference them by name), I think you probably have to do math and figure out the right index to use. Following from the example in (3) above, I think the next component is
component[3].
:scared:
Elliot Silver (Nov 27 2020 at 22:14):
Along with detecting skipped array indices, it would be nice to detect repeated assignment and/or duplicated indices. For example, if I have the following line in my questionnaire twice, it is probably an error.
* item[4].item[2].type = ...
Two occurrences of this line likely mean:
- I've misnumbered something and the two occurrences should be referring to different items
- The assigned values are identical, and one occurrence is therefore redundant
- The assigned values are different, and one occurrence is therefore misleading.
- It is an erroneous attempt to set multiple values in an array.
Although I first thought of this in the array context, I don't see why it wouldn't also apply to any assignments.
I don't have a use case for why someone would want to have duplicate assignment, but I suggest only making this a warning, just in case.
Chris Moesel (Nov 29 2020 at 19:47):
Hi @Elliot Silver -- I can think of one use case, but really it's almost more of an artifact of how SUSHI is implemented. If a RuleSet has several rules, including assignments, then maybe someone would want to insert the rule set and then override one or more of the assignments. Looking at the FSH where the rule set is used, you would not see the duplication -- but after expansion, it is there. That said, we could probably be smart enough to detect that specific case and not warn on it.
Chris Moesel (Nov 29 2020 at 19:47):
If this is a feature you would like, please feel free to log an issue over at https://github.com/FHIR/sushi/issues
Last updated: Apr 12 2022 at 19:14 UTC
