You know what, I'm just going to change ParseException to match the behavior of ParseBuffer::Exception, and remove ParseBuffer::Exception. (Maybe I can leave a "typedef ParseException Exception;" in ParseBuffer.hxx to maintain compatibility with existing app code; what do you think?) There are lots of places in the code that assume parse failures throw a ParseBuffer::Exception, and we can expect that this mistake will be made again in the future if we aren't proactive now.
Best regards, Byron Campen
If we can guarantee that all parsing exceptions will be of a common class (or a small number of classes), I am all for this. However, I discovered lately that there is at least one additional exception that is thrown by some of the parameter classes (ParseException). For the time being, I have clamped down completely. If we could move ParseException.hxx to rutil, and derive ParseBuffer::Exception from it (or just have ParseBuffer throw a plain-old ParseException), we'd (hopefully) be back to having a single exception class to serve our parse-failure needs.
Best regards, Byron Campen I'm not sure that I agree with this particular change. isWellFormed should only catch parse exceptions. Any other exception can't be handled in this context and should be passed up. Is there a specific situation that you are trying to guard against here?
_______________________________________________ resiprocate-devel mailing list
_______________________________________________ resiprocate-devel mailing list
|