Thread overview | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 07, 2013 std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Apologies if this has been talked about before. I haven't been able to find it by a quick search of the 'group. Apologies also if what I'm saying is already taken care of in the module that's being drafted as a replacement for std.xml. This is what I've found: Validity checking is done in an in contract! This is saying it's _illegal_ to construct a Document or DocumentParser from invalid XML, not just that it's an error condition. This is contrary to the spirit of DBC and exception handling. DBC is for detecting program bugs. Exception handling is for dealing with unexpected conditions at runtime. 99% of the time, XML data will come from a file or an external process, rather than being hard-coded in the program or even generated by and passed from another part of the program. As such, invalid XML input is an unexpected condition at runtime, verifying that the XML is syntactically and structurally valid is part of what the program needs to do. An invalid XML file is not a sign of a bug in a program - indeed, the failure to detect the invalidity of an XML file is. This means that rather than just Document data = new Document(xml); you need to do check(xml); Document data = new Document(xml); Consequently, in a development build the XML is parsed three times: - first, through the call to the check function here - then, when check is called again in DocumentParser's constructor's in contract - and finally, in the body of the Document constructor as it is actually building the DOM. This shouldn't be necessary. Validity should be checked automatically while parsing the XML to build the DOM. This would mean that the XML is parsed only once, which is much more efficient as well as being a first step towards enabling the XML to be read from a stream and parsed on the fly. And it should throw a normal exception if it fails, not an assertion failure. I haven't taken the time to figure out what actually does happen if malformed XML is passed in in a release build. But I don't suppose that it errors out gracefully in the general case. Anyway ... is there going to be a fix for this, or is it just a case of waiting for the replacement for std.xml and using the workaround or an alternative XML parser in the meantime? Stewart. |
February 07, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | On Thursday, 7 February 2013 at 22:22:09 UTC, Stewart Gordon wrote:
> This is what I've found: Validity checking is done in an in contract!
I've ran into the same problem with std.base64. DbC doesn't seem to be a generally well-understood concept.
|
February 07, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | std.xml itself is known to be absurd. I haven't used it myself, but there's been a general consensus for years that it needs a complete rewrite. Attempts have been started, but nobody's finished one, AFAIK. You could try the XML module in Tango, it's supposed to be ridiculously fast. |
February 07, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | On 2/7/13 5:22 PM, Stewart Gordon wrote:
> Apologies if this has been talked about before. I haven't been able to
> find it by a quick search of the 'group. Apologies also if what I'm
> saying is already taken care of in the module that's being drafted as a
> replacement for std.xml.
>
> This is what I've found: Validity checking is done in an in contract!
Please submit a bug report. Thanks!
Andrei
|
February 07, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On 2/7/13 5:27 PM, Vladimir Panteleev wrote:
> On Thursday, 7 February 2013 at 22:22:09 UTC, Stewart Gordon wrote:
>> This is what I've found: Validity checking is done in an in contract!
>
> I've ran into the same problem with std.base64. DbC doesn't seem to be a
> generally well-understood concept.
That's why TDPL dedicates a whole chapter to it (separate from error handling!). Apparently that didn't make a dent in the Universe :o).
Andrei
|
February 08, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | Am 07.02.2013 23:35, schrieb Nick Sabalausky: > std.xml itself is known to be absurd. I haven't used it myself, > but there's been a general consensus for years that it needs a complete > rewrite. Attempts have been started, but nobody's finished one, > AFAIK. You could try the XML module in Tango, it's supposed to be > ridiculously fast. > There is also http://opticron.no-ip.org/svn/branches/kxml/ |
February 08, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 07/02/2013 22:36, Andrei Alexandrescu wrote: <snip> > Please submit a bug report. Thanks! http://d.puremagic.com/issues/show_bug.cgi?id=9471 |
February 08, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Am Thu, 07 Feb 2013 17:36:53 -0500 schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>: > On 2/7/13 5:27 PM, Vladimir Panteleev wrote: > > On Thursday, 7 February 2013 at 22:22:09 UTC, Stewart Gordon wrote: > >> This is what I've found: Validity checking is done in an in contract! > > > > I've ran into the same problem with std.base64. DbC doesn't seem to be a generally well-understood concept. > > That's why TDPL dedicates a whole chapter to it (separate from error handling!). Apparently that didn't make a dent in the Universe :o). > > Andrei I'm just thinking that http://wiki.dlang.org/Phobos could be extended by a review process check-list which includes "correct use of DBC", "use of ranges where appropriate" and whatever else is desired for Phobos. Another term would be Quality Standards. -- Marco |
February 08, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 2013-02-07 23:35, Nick Sabalausky wrote: > std.xml itself is known to be absurd. I haven't used it myself, > but there's been a general consensus for years that it needs a complete > rewrite. Attempts have been started, but nobody's finished one, > AFAIK. You could try the XML module in Tango, it's supposed to be > ridiculously fast. It is fast, but it doesn't perform any validations. I have no idea what happens if pass invalid XML to it. -- /Jacob Carlborg |
February 08, 2013 Re: std.xml validity checking is absurd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Thursday, 7 February 2013 at 22:36:53 UTC, Andrei Alexandrescu wrote: > On 2/7/13 5:27 PM, Vladimir Panteleev wrote: >> On Thursday, 7 February 2013 at 22:22:09 UTC, Stewart Gordon wrote: >>> This is what I've found: Validity checking is done in an in contract! >> >> I've ran into the same problem with std.base64. DbC doesn't seem to be a >> generally well-understood concept. > > That's why TDPL dedicates a whole chapter to it (separate from error handling!). Apparently that didn't make a dent in the Universe :o). > > Andrei "in" and "out" contracts themselves are flawed in D in any case, given they are part of the "called" code, as opposed to "caller" code. This makes them absolutely no different than an assert. The problem is that an assert is "internal" validation, whereas an "in"/"out" is supposed to be a handshake between the caller/callee. If I write an "sqrt" function, and document it as "Please, only give me positive numbers", and then write a contract for it, and then compile my lib in release, the caller will have no way of "signing" my contract. He'll call my sqrt with negative numbers, and the in will never get called, and sqrt will crash horribly. A *BLATANT* example of this limitation is slice operations: They have an in contract stating that the slices need to be the same length. However, this contract will never ever get run, for anyone, because druntime is built and distributed in release. Long story short, even if I compile in debug, the code will silently run erroneously. http://d.puremagic.com/issues/show_bug.cgi?id=8650 Please see also: http://d.puremagic.com/issues/show_bug.cgi?id=4720 http://d.puremagic.com/issues/show_bug.cgi?id=6549 And finally, this old thread about the subject, which kind of fell into darkness: http://forum.dlang.org/thread/jamrtmgozgtswdadeocg@forum.dlang.org |
Copyright © 1999-2021 by the D Language Foundation