Hi, Since I confess to be guilty of having started this, I guess you should be aware of my position as well: I think that it is beneficial to catch errors which are caused by trying to assign a default value to non-defaultable items as soon as the issue is detected. My main points are that this makes the code more robust (because the binary won't crash after possibly hours of execution if it suddenly tries do accessing such an invalid item) and it makes the higher level code simpler and easier to maintain (because it can rely on the fact that all non-defaultable items are present after the deck has been successfully parsed).
Having said that, I can also see Joakim's point of not wanting to add "bogus"
defaults to the JSON files just to be able to terminate keywords early. As far
as I can see, this only affects the property modifier keywords (ADD, COPY,
MULTIPLY...) though, and I'd prefer to bite that bullet than placing an "if()"
around every single access to items in the higher level code...
cheers
Andreas
On Tuesday, December 09, 2014 18:33:20 Joakim Hove wrote:
> Sorry I forget one aspect:
>
>
> *Parser & defaults*: The default values are used in two cases:
>
>
> 1. If the deck contains explicit default markers of the form 'n*'
> 2. If a record is terminated prematurely.
>
> If the Json configuration has a default value specified for the item(s) in
> question it is simple - the deck item is initialized with the default value
> and everything is hunka dory. However - what to do if the item does not
> have a default value specified, e.g.
>
>
> WELSPECS
>
> / --- A fully defaulted record
>
> / -- Keyword termination
>
>
> This keyword clearly does not make much sense, and Eclipse will abort
> during the parse stage. I want the parser to accept this, and then let the
> Schedule constructor throw an exception when we are trying to access the
> unitialized values of the WELSPECS keyword. For the example at hand this
> might seem a bit relaxed - and the Eclipse behaviour more sensible; however
> there many cases where the actual default value can not be used (i.e. use
> -1 to indicate no limit for ...) and the calling scope must take care in
> differentiating between a valid -1 and a defaulted -1; in addition the Json
> configuration must have many default values which can not really be used as
> such - they only serve as markers of default behaviour; I would prefer to
> avoid filling up the configuration with such invalid values.
>
> joakim
--
the unix philosophy: do 90% of one thing, and barely do it adequately
-- Adam Jackson
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
