BIND 10 #2369: InputSource helper class for MasterLexer

[BIND 10 Development]

#2369: InputSource helper class for MasterLexer
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121106
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  libdns++                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  loadzone-ng                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:19 muks]:

 > > In my attempt of integrating this branch into #2371, I noticed a few
 > > more things:
 > >
 > > - I suggest including what's wrong when throwing OpenError:
 > > {{{#!cpp
 > >         isc_throw(OpenError,
 > >                   "Error opening the input source file: " <<
 filename);
 > > }}}
 > >   "no such file", "permission denied", etc.
 > > - if not super hard, I'd test a different failure case for `OpenError`
 > >   like it's not readable (due to permission or possible some other
 > >   reason)
 >
 > I'd like to do these two, and return the appropriate error, but I could
 not find a way of getting such messages from fstream. It's possible to
 make fstream throw an exception by setting the exception bits, but the
 description (`ex.what()`) contains a weird message "basic_ios::clear". We
 can alternatively check `stat()` output, but it's better to get a proper
 error from fstream if it's possible.

 Hmm, apparently there's no guaranteed way of getting such information
 from fstream:
 http://stackoverflow.com/questions/960541/detecting-reason-for-failure-to-
 open-an-ofstream-when-fail-is-true

 One solution is to use C-API such as fopen (and other C-API for
 subsequent read), but it wouldn't make sense to do it if it's only
 benefit is to get an error at open.

 Although still non-portable and not guaranteed, maybe we can use
 errno as a hint:
 {{{#!cpp
     errno = 0
     file_stream_.open(filename, std::fstream::in);
     if (file_stream_.fail()) {
         std::string error_txt = "Error opening the input source file: "
                                  + filename";
         if (errno != 0) {
             error_txt += ": (possible cause) " + strerror(errno);
         }
         isc_throw(OpenError, error_txt);
     }
 }}}
 If this works in some commonly used platforms, it'd be still much
 better than saying nothing.

 BTW: yet another thing I noticed: I think we should specify 'explicit'
 for the constructors:

 {{{#!cpp
     /// \brief Constructor which takes an input stream. The stream is
     /// read-from, but it is not closed.
     explicit InputSource(std::istream& input_stream);

     /// \brief Constructor which takes a filename to read from. The
     /// associated file stream is managed internally.
     ///
     /// \throws OpenError when opening the input file fails.
     explicit InputSource(const char* filename);
 }}}

 Although the construction usage is very limited and the possibility of
 confusing implicit conversion would be very small, I suspect the
 latter one can potentially cause a quite annoying surprise.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2369#comment:21>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development