mbeckerle commented on a change in pull request #226: Sick of NPE.
lexicalParent is now optLexicalParent and is Option type
URL: https://github.com/apache/incubator-daffodil/pull/226#discussion_r291169337
##########
File path:
daffodil-core/src/main/scala/org/apache/daffodil/dsom/SchemaComponentFactory.scala
##########
@@ -79,14 +81,14 @@ trait SchemaFileLocatableImpl
trait CommonContextMixin
extends NestingMixin { self: OOLAGHost with ThrowsSDE =>
- def lexicalParent: SchemaComponent
+ def optLexicalParent: Option[SchemaComponent]
- lazy val schemaFile: Option[DFDLSchemaFile] = lexicalParent.schemaFile
- lazy val schemaSet: SchemaSet = lexicalParent.schemaSet
- def schemaDocument: SchemaDocument = lexicalParent.schemaDocument
- lazy val xmlSchemaDocument: XMLSchemaDocument =
lexicalParent.xmlSchemaDocument
- lazy val schema: Schema = lexicalParent.schema
- def uriString: String = lexicalParent.uriString
+ lazy val schemaFile: Option[DFDLSchemaFile] = optLexicalParent.flatMap {
_.schemaFile }
Review comment:
We do have a mixture here of non-opt-handling, and option code. There is
rhyme and reason to this. For the most part, oolag framework lets you just
write code that assumes certain things are present, and if they aren't captures
it and you get an SDE out of it, ascribed to the nearest calling OOLAG LV
object. So the code doesn't have to always deal with option values. On the
other hand, quite often you need to know if something is present or not, as the
logic simply requires it. For this optLexicalParent, for the most part code
just assumes everything has a lexical parent. The point of adding it, is just
to catch algorithm problems where you run up the hierarchy unconditionally, and
aren't checking for the root. This happened enough times, and NPEs are
problematic enough in the debugger that I had to change this.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
