[新特性] 完成Assert 断言工具类,函数接口延迟获取错误信息接口

[freshgeek]

说明

1. 请确认你提交的PR是到'v5-dev'分支，否则我会手动修改代码并关闭PR。
2. 请确认没有更改代码风格（如tab缩进）
3. 新特性添加请确认注释完备，如有必要，请在src/test/java下添加Junit测试用例

修改描述(包括说明bug修复还是新特性添加)

2. [新特性] 完成Assert 断言工具类,函数接口延迟获取错误信息接口

[freshgeek]

#1162

[looly]

这里重复判断了哦，而且推荐false == expression

[freshgeek]

好的,idea 推荐直接! ,哈哈哈哈 , 遵循项目规范

但是,这个地方需要在外面嵌套一层判断,不然延迟调用效果将无效 ,

[looly]

感谢pr，非常辛苦的工作，哈哈。

不过前面的isTrue重复判断了，这块我会做下修改。

[looly]

额……和以前的方法冲突了。

public static <X extends Throwable> void isTrue(boolean expression, Func0<? extends X> supplier) throws X {

以前有自定义异常。

[freshgeek]

额……和以前的方法冲突了。

public static <X extends Throwable> void isTrue(boolean expression, Func0<? extends X> supplier) throws X {

以前有自定义异常。

自定义异常是什么场景下使用呢?

[freshgeek]

针对不同的异常 添加全局异常处理 会不会好点

[looly]

自定义异常场景非常多。比如在框架中，业务层需要统一处理某种类型异常，这个时候如果写死异常类型，那捕获异常会变得很麻烦。

[freshgeek]

对哦 感觉业务场景 适用于直接生产消息,而不那么关注异常类型 , 框架中更关注 异常类型

当时我加代码时也有考虑到这一点,我后面的那些数值比较就没有添加延迟获取拓展

[looly]

所以为了更好适应，我会把你的pr修改为更加通用性：

public static <X extends Throwable> void isNull(Object object, Supplier<X> errorSupplier) throws X {
	if (null != object) {
		throw errorSupplier.get();
	}
}

[freshgeek]

那这样针对业务场景就不是那么友好了 ,

如果需要使用延迟获取异常消息的话,需要在获取错误消息外再包装一层异常类

两者共存会不会更适用于一个工具类,这也正好迎合 重载 的特性

需要生产错误消息使用这个 ,生产异常类使用另外一个