Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert all assertions to verify #212

Closed
gavin-norman-sociomantic opened this issue Aug 15, 2017 · 30 comments
Closed

Convert all assertions to verify #212

gavin-norman-sociomantic opened this issue Aug 15, 2017 · 30 comments

Comments

@gavin-norman-sociomantic

As discussed many time in the past, the different behaviour of assertions in D1/D2 is problematic. To quote some previous discussion:

The main problem with the proposed "design by contract" model is the assumption that once the program is sufficiently tested in debug mode it is safe to remove assertions and contracts without compromising correctness (for better performance).

However, in the case of a server application working primarily with external data, it is very hard to get to the point of such confidence, especially if any error can have a potentially very costly impact on business. Even full test coverage can be misleading. This has resulted in some application never using the -release flag out of fear of possible uncaught programmer errors.

After some discussion, it was agreed that we need a more practical approach to using contracts, even if it will violate the intended DbC ideology. Most known issues seem to be associated with in contracts, because those do not notify the programmer when violation of some internal assumption occurs but rather at some later point when the violation is about to cause application corruption and must be protected against at all costs.

At the same time, the actual performance penalty of calling such safety checks is often very small, being as simple as checking for null pointers or integer boundaries. Any possible performance gain is simply not worth the added risk of removing the check (one case where it can make a difference, though, is in very small functions where extra operations can make the difference between inlining or not).

Indeed, we are now at the stage of running important server apps in D2 builds and need to address this issue (the change of assertion behaviour) before progressing.

@leandro-lucarella-sociomantic
Copy link
Contributor

Related to #213, I wonder if we should finally introduce this programming error before doing this conversion.

@mathias-lang-sociomantic
Copy link
Contributor

How do we deal with bounds checking ?

@nemanja-boric-sociomantic
Copy link
Contributor

It was discussed to move with the ocean compiled as a library with -release.

@mathias-lang-sociomantic
Copy link
Contributor

It means we have to compile the whole project with -release or am I missing something ?

@mihails-strasuns-sociomantic
Copy link
Contributor

How do we deal with bounds checking ?

I don't see way out of it other than protect all places where it may happen with preceding enforce/verify of some sort.

It means we have to compile the whole project with -release or am I missing something ?

I think it should be the goal eventually but of course that requires similar adjustments of other libs and thus will take plenty of time. Idea of providing copy-paste makd snippet to link ocean as -release built static library is one way to make such slow transition less painful.

@leandro-lucarella-sociomantic
Copy link
Contributor

I don't see way out of it other than protect all places where it may happen with preceding enforce/verify of some sort.

This really sucks and I think is not practical. OK, we can minimize then the Error problem, but we can't rely on getting rid of it completely, which will still be somehow problematic.

@mihails-strasuns-sociomantic
Copy link
Contributor

I actually don't think it is that bad. We rarely try to index arrays with some data that is not directly derived from its .length without previously doing some sanity checking on it - and that sounds like a reasonable approach overall. Code like this one https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/util/serialize/contiguous/Deserializer.d#L314 seems common.

@leandro-lucarella-sociomantic
Copy link
Contributor

But the whole point of this is for times when someone forgets to do the sanity checks :)
I see your point about not being the end of the world though, but I think it is still risky to have cases where the program can explode in your face when it is avoidable.

@mihails-strasuns-sociomantic
Copy link
Contributor

mihails-strasuns-sociomantic commented Aug 17, 2017

I agree with that but to me it seems much more likely to be caught at (unit)testing stage than failed contract and thus much further in the realm of acceptable.

@gavin-norman-sociomantic gavin-norman-sociomantic changed the title Convert all assertions to enforce Convert all assertions to verify Aug 31, 2017
@gavin-norman-sociomantic
Copy link
Author

PR updating the error handling guidelines: sociomantic-tsunami/sociomantic#10

@mihails-strasuns-sociomantic
Copy link
Contributor

Also related - #96

@gavin-norman-sociomantic
Copy link
Author

gavin-norman-sociomantic commented Sep 5, 2017

Breakdown of assert occurrences by top-level package:

  • core: 472
  • io: 586
  • math: 900
  • meta: 191
  • net: 202
  • stdc: 14
  • sys: 54
  • task: 32
  • text: 1339
  • time: 601
  • util: 1187

It might be a good idea to strip out unused code before doing this. (Or deprecate and not bother assessing deprecated code for assertions.)

@gavin-norman-sociomantic
Copy link
Author

Some easy cases exist in old unittests that were never converted to use test instead of assert.

@gavin-norman-sociomantic
Copy link
Author

Some easy cases exist in old unittests that were never converted to use test instead of assert.

It might be possible to auto-convert these using d1to2fix. @mihails-strasuns-sociomantic what do you think?

@mihails-strasuns-sociomantic
Copy link
Contributor

Shouldn't be too hard. I'll have a look.

@gavin-norman-sociomantic
Copy link
Author

Excellent. Let's try to do that first, then we can assess what remains.

@gavin-norman-sociomantic
Copy link
Author

gavin-norman-sociomantic commented Sep 8, 2017

After merging #241:

  • core: 168
  • io: 340
  • math: 322
  • meta: 29 (already done)
  • net: 67
  • stdc: 2
  • sys: 37
  • task: 38 (already done)
  • text: 312
  • time: 29
  • util: 562

@gavin-norman-sociomantic
Copy link
Author

(Adjusted numbers above, filtering out static assert.)

@gavin-norman-sociomantic
Copy link
Author

gavin-norman-sociomantic commented Sep 8, 2017

Looks like splitting it six ways might work:

  • io
  • math
  • text
  • util part 1
  • util part 2
  • The rest

@mihails-strasuns-sociomantic
Copy link
Contributor

I'd like to take core :)

@gavin-norman-sociomantic
Copy link
Author

core is included in "the rest" ;)

@mathias-lang-sociomantic
Copy link
Contributor

I volunteer as a tribute for text :)

@gavin-norman-sociomantic
Copy link
Author

The easiest way to split util would be util.container and everything else. container has 387 / 562 asserts.

I'm happy to take container.

@gavin-norman-sociomantic gavin-norman-sociomantic added this to the v3.5.0 milestone Sep 14, 2017
@mihails-strasuns-sociomantic
Copy link
Contributor

This finished for initial conversion, right?

@mathias-lang-sociomantic
Copy link
Contributor

I haven't done my share yet 😊

@mihails-strasuns-sociomantic
Copy link
Contributor

@mathias-lang-sociomantic do you think you can get to it in next few days? Otherwise I am going to take it over as I want to release 3.5.0 this Friday :)

@mathias-lang-sociomantic
Copy link
Contributor

I definitely won't be able to start before Thursday at best (Brighton), so maybe it's better if you take over, sorry :(

@mihails-strasuns-sociomantic
Copy link
Contributor

No problem!

@mihails-strasuns-sociomantic
Copy link
Contributor

ocean.text merged - #276

That should be it for the first stage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants