Hi, On Wednesday, December 10, 2014 13:23:38 Joakim Hove wrote: > Since I confess to be guilty of having started this, I guess > you should be aware of my position as well: > > > > Good - thank you. > > > > 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). > > > > The phrase: "because the binary won't crash after possibly hours of > execution if it suddenly tries do accessing such an invalid item" is quite > misleading for my position; if an item without default is missing it should > raise an exception when forming the EclipseState - i.e. a long time before > any simulation has started.> However - the underlying assumption behind that > argument (which I had frankly forgotten) is of course that all higher level > code is accessing the deck properties through the EclipseState object and > not the deck directly. That is certainly the direction I want to move > things - but we are not there yet.
yep, 100% agreement from my side :)
cheers
Andreas
--
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
