断言不是错误！

断言机制估计很多道友都用过，在 ST 的标准库中，经常可以看到它的身影：

它的实现方式也是非常简单的，就是通过 USE_FULL_ASSERT 宏进行控制：

如果断言失败，就会执行 assert_failed 函数，一般实现函数如下：

void assert_failed (uint8_t* file, uint32_t line)

{

static char buff[128];

sprintf (buff,"%s,%d", file, line);

__breakpoint(0);

}

当然这里的 sprintf 函数也常常使用 printf 代替，这样就可以直接通过串口打印出来了，而鱼鹰这个在没有串口的情况下，可以通过内存 buff 显示出来，比较方便在线调试。

而 __breakpoint(0) 一般由死循环 while(1) 代替，而鱼鹰觉得 while(1) 不够好，因为断言失败后，可能很久你才能发现而进入该死循环，而使用 __breakpoint 可以让你在 在线调试 模式下，立刻停止程序运行，从而可以快速定位问题。

不管哪种实现方式，断言失败的结果一般只有暂停程序了，类似 linux 内核的 panic 。

而这是设计者希望看到的，但有些开发者认为不应该这样，因为程序一旦死循环，如果开启了看门狗，会导致整个程序复位，对于产品而言，复位是很严重的 BUG 。

“我不希望我的产品复位，所以请修改你的代码，不让他产生断言失败，可以吗？”

不可以。

断言本身不是错误，它只是发现你程序的 BUG ，进而提醒你。

断言失败，往往是很严重的问题，严重到这段代码或功能无法正常执行，所以你修改的地方应该是调用者，而不是产生断言的代码，请不要颠倒主次，否则没有从根本上解决问题。

就比如最上面的 GPIO 外设指针检查断言部分，如果调用者传入一个非 GPIO 的指针进入函数，从而产生断言失败，那么你会选择关闭断言机制还是说检查你的代码是否存在问题呢？

当然是后者。

所以，如果产生了断言失败的情况，请不要慌，不要认为这是一种错误，而应该根据断言失败的位置，定位断言失败的根本原因，而不是试图通过关闭断言的方式让程序继续运行下去，这只会让你的程序运行得更糟糕，同时也更难定位问题。