AlwaysAssert.alwaysAssert()

[GoogleCodeExporter]

Class Preconditions is a good start for allowing users to add library-based
Design by Contract constructs to their code.  This should be expanded by
offering other classes, for example, Invariant and Postconditions.  Move
some methods from Preconditions (like checkState() to Invariant) and add
other methods (like checkReturn() to Postconditions).

Perhaps a new package, com.google.common.dbc, is in order?

Also, I would like to see better integration with Predicates.  Basically,
for every method like:

checkArgument(boolean b)

there should be a method like:

checkArgument(Predicate<T> p, T object)

This would allow clients of Preconditions to express their conditions more
compactly.

Original issue reported on code.google.com by russ.mil...@gmail.com on 25 Mar 2009 at 3:18

[GoogleCodeExporter]

We're working on this.  Making the right API decisions to satisfy everyone is
extremely difficult.  The current, as of yesterday, notion is:

* For any check you'd never have to make if you completely trusted your caller, 
use
Preconditions.
* For any check which should absolutely never fail in production no matter 
what, use
the Java assert facility.
* For all other checks, use ______.

The blank could be filled in with

Invariants.invariant()
Expectations.expect()
Expect.expect()
Checks.check()

As for your Predicate idea, I think it's good, but Predicate is not quite the 
right
construct because once you start using a complex one, you then get no feedback 
at all
about what part of the complex predicate failed.  My long-term goal is to 
expand the
concept of com.google.common.collect.Constraint to become something that is 
perfect
for this use case as well as validating *user* input which is a whole other 
beast.

Original comment by kevin...@gmail.com on 25 Mar 2009 at 3:32

[GoogleCodeExporter]

Thanks for the quick feedback, Kevin.

> For any check which should absolutely never fail in production no
> matter what, use the Java assert facility

> For all other checks...

You seem to imply that there some checks that would be OK to fail in 
*non-production*
environments, or that there are some that *are* OK to fail in production
environments.  Do you really mean this?  IMHO, a check is a check is a check.  
If
it's in the code, it should never fail.

I would also argue that the Java assertion facility isn't the best option for
catching those "which should absolutely never fail in production", because code 
can
always be run (and probably *would* be run) in production with assertions 
turned off
(it depends; if the code is QA'ed with assertions on, then it goes into 
production
that way, and vice-versa).

I haven't looked at Constraint much.  I'll do that now.  I see your point about 
not
knowing where a complex predicate failed, but I think I would take the ability 
to
express all my checks as a centralized, reusable Predicate with that caveat.  
The
ability to use an enhanced Constraint could be added later, if needed.

Of course I have that ability now:

checkArgument(myPredicate.apply(myObject));

but it would be nice to be able to say:

checkArgument(myPredicate, myObject);

Admittedly, not much more compact, but that about:

checkArgument(Predicates.notNull().apply(obj1));
checkArgument(Predicates.notNull().apply(obj2));
checkArgument(Predicates.notNull().apply(obj3));

versus:

checkArgument(Predicates.notNull(), obj1, obj2, obj3);

Original comment by russ.mil...@gmail.com on 25 Mar 2009 at 4:07

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:57

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 6:02

• Added labels: Milestone-Post1.0

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 Jul 2010 at 3:53

• Removed labels: Milestone-Post1.0

[GoogleCodeExporter]

I would also like to see the use of Predicates for all possible checks.
This would give the possibility to return the validated argument as notNull 
does this already!

Original comment by vitz.michael@googlemail.com on 1 Nov 2010 at 10:36

[GoogleCodeExporter]

I'd like to suggest the following smal, trivial enhancement to Preconditions. 
Addition of a checkNotEmpty() method for Strings and Collections that look like:

public static <T extends Collection<?>> T checkNotEmpty( final T aCollection ){
        if( aCollection == null || aCollection.isEmpty() ) throw new IllegalArgumentException();
        return aCollection;
}

ditto for String (modulo all the generic nonsense).

(Or is such a util somehwere else and I've simply missed it?)

Original comment by mikro...@gmail.com on 9 Dec 2010 at 10:03

[GoogleCodeExporter]

I can see how

  this.list = checkNotEmpty(inputList);

is a little bit more compact than

  checkArgument(!inputList.isEmpty());
  this.list = inputList;

But if we started down this road, there is no clear stopping point.  We're 
instead evaluating a possible generalization of any argument or state check.

Original comment by kevinb@google.com on 9 Dec 2010 at 6:32

[GoogleCodeExporter]

Original comment by fry@google.com on 26 Jan 2011 at 9:55

• Changed state: Accepted

[GoogleCodeExporter]

I'd love to see a checkNotEmpty for string parameters.

Original comment by steven.b...@gmail.com on 12 Feb 2011 at 5:15

[GoogleCodeExporter]

Original comment by kevinb@google.com on 13 Jul 2011 at 6:18

• Changed state: Triaged

[GoogleCodeExporter]

Original comment by kevinb@google.com on 16 Jul 2011 at 8:37

• Changed state: Accepted

[GoogleCodeExporter]

>> For any check which should absolutely never fail in production no
>> matter what, use the Java assert facility
>> For all other checks...
>
>You seem to imply that there some checks that would be OK to fail in 
*non-production*
environments, or that there are some that *are* OK to fail in production
environments.  Do you really mean this?  IMHO, a check is a check is a check.  
If
it's in the code, it should never fail.

Let me try rephrasing: these are tests that we expect to always, always, always 
pass wherever they are, but we don't want them to be run in prod because they'd 
slow down execution.

Original comment by wasserman.louis on 25 Aug 2011 at 10:24

[GoogleCodeExporter]

Original comment by fry@google.com on 10 Dec 2011 at 3:36

• Added labels: Package-Base

[GoogleCodeExporter]

There could many things this bug is trying to ask for but here is the thing we 
are doing right now; please open separate bugs to ask for separate things won't 
cover.

We want to provide a method that is used like assert and behaves like assert 
except is always enabled in production.  We believe this covers the lion's 
share of runtime checks that are not already covered by Preconditions.

Original comment by kevinb@google.com on 16 Feb 2012 at 6:38

• Changed title: AlwaysAssert.alwaysAssert()

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 May 2012 at 7:43

• Added labels: Type-Addition
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Issue 1381 has been merged into this issue.

Original comment by wasserman.louis on 23 Apr 2013 at 8:45

[GoogleCodeExporter]

Any update on adding this "always assert" method?

Original comment by electrum on 23 Apr 2013 at 10:37

[GoogleCodeExporter]

@electrum: I'm going to try to make this happen soon.

Original comment by kurt.kluever on 24 Apr 2013 at 2:50

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:16

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:19

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:10

• Added labels: Restrict-AddIssueComment-Commit