From ramises.silva at kryptus.com Tue Oct 17 11:41:34 2017 From: ramises.silva at kryptus.com (=?UTF-8?Q?Ramis=C3=A9s_Martins_da_Silva?=) Date: Tue Oct 17 13:49:11 2017 Subject: [studxml-users] Asserts in next_expect functions Message-ID: Hi, I'm curious about the "next_expect functions that also set the content". In it's implementation it is asserted that the event must be a start_element. My question is if the placement of this assert inside the function is important. For me it seems more natural that a blocking condition like an invalid parameter test comes first in the function. -- *Ramis?s Martins* From boris at codesynthesis.com Wed Oct 18 10:59:10 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Oct 18 10:59:19 2017 Subject: [studxml-users] Asserts in next_expect functions In-Reply-To: References: Message-ID: Ramis?s Martins da Silva writes: > I'm curious about the "next_expect functions that also set the content". In > it's implementation it is asserted that the event must be a start_element. > My question is if the placement of this assert inside the function is > important. For me it seems more natural that a blocking condition like an > invalid parameter test comes first in the function. Yes, I agree, and am not sure why we did it this way. Fixed for the next release, thanks! Boris From pedro at kryptus.com Wed Oct 18 13:52:08 2017 From: pedro at kryptus.com (Pedro Calixto) Date: Wed Oct 18 13:52:22 2017 Subject: [studxml-users] Asserts in next_expect functions In-Reply-To: References: Message-ID: <93087730-2225-d1cf-7f58-689feeefdf94@kryptus.com> There is a difference, however, between these assertion placements. To test it, I moved the assertion found in /inline void parser::next_expect (event_type e, const std::string& ns, const std::string& n,?//content_type c)/ (parser.ixx) to the beginning of this function. The parsed xml was: ? John Doe The code that tested it was: int main(int argc, char *argv[]) { ? std::ifstream ifs(argv[1]); ? xml::parser p(ifs, argv[1]); ? std::string const Name("animal"); ? std::string const Ns(""); ? auto Content = xml::content(xml::content::complex); ? p.next_expect(xml::parser::end_element, Ns, Name, Content); ? return 0; } Before moving the assertion to the beginning, there was an exception thrown (parsing), and the program output was: terminate called after throwing an instance of 'xml::parsing' ? what():? error.xml:2:0: error: end element 'animal' expected Aborted (core dumped) After moving the assertion to the beginning, there was no exception, but the assertion error: main: /usr/local/include/xml/parser.ixx:136: void xml::parser::next_expect(xml::parser::event_type, const string&, const string&, xml::parser::content_type): Assertion `e == start_element' failed. Aborted (core dumped) I wonder which alternative would be better for displaying the error to the user, since the exception description feels more clear about what was wrong (IMO). -- Pedro Calixto, Estagi?rio KRYPTUS EED S/A Trust in Cybersecurity +55 19 3112 5000 www.kryptus.com From boris at codesynthesis.com Thu Oct 19 13:40:28 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Oct 19 13:40:36 2017 Subject: [studxml-users] Asserts in next_expect functions In-Reply-To: <93087730-2225-d1cf-7f58-689feeefdf94@kryptus.com> References: <93087730-2225-d1cf-7f58-689feeefdf94@kryptus.com> Message-ID: Pedro Calixto writes: > There is a difference, however, between these assertion placements. The assertion checks the function pre-condition which is that it should only be called for start_element events. To put it another way, if the assertion is triggered, then the code that called next_expect() is invalid. If the exception is thrown, then the XML provided by the user is invalid. In most cases you want to find out that your code is broken as soon as possible. Boris