Python编程中，写程序时需要考虑理论上概率为零的意外情况吗？
比如一个数值输入计算，要先判断它是否全为数字，然后再计算
Python编程中，写程序时需要考虑理论上概率为零的意外情况吗？
当然要考虑。理论上概率为零的意外情况，在实际编程中往往是导致程序崩溃或产生不可预测行为的根源。比如，从理论上讲，一个均匀分布的随机数生成器恰好生成0.5的概率是零，但如果你写 if x == 0.5:，这个分支在理论上是有可能被触发的，因为浮点数精度问题，x 可能非常接近但不等于0.5，导致逻辑错误。
更常见的例子是处理外部输入或系统资源。理论上，你打开一个文件，它应该存在，但用户可能删了它；分配内存应该成功，但系统可能耗尽了内存。这些情况在“理想”的理论模型里概率为零，但在现实世界里天天发生。
所以，防御性编程是关键。对于可能失败的操作，使用 try-except 来捕获异常；对于可能为 None 的值，在使用前先判断；对于浮点数比较，使用容差而不是直接相等。别指望理论概率，要处理实际可能发生的一切。
总结：必须考虑，这是健壮代码的基础。
因为计算机处理的内容是离散的，所以概率是 0 等同于不可能，不用处理。甚至小概率情况也不用管，比如硬件故障，这种完全管不了的情况也没法管。
但是期待用户输入的东西，用户输入乱七八糟的内容还是很有可能的，譬如：
- 用户输入了全角数字字符；
- 用户输入小数点的时候输入成了句号；
- 用户不小心在数字中间加了空格；
- 用户使用了千位分隔符，而你以为大家都不用千位分隔符；
- 用户使用 , 作为小数分隔符、使用 . 作为千位分隔符；
- 用户误触键盘其他键但是忘了删掉或者手太快；
- ……
工作认真对待该处理就处理；自己私下的小玩具就随意了。不过还是养成习惯最好。
工作上，我一般直接给 return ；
私下的朋友间的玩具，一般都是：
print(“搞事啊！！”);
exit(1)
#滑稽
不是很理解你这个理论上为 0 ……
放在实际开发中，确实是能想到的错误出现的概率都不见得为 0 。即使是内存 bit 读写会翻转，这种问题放到一些环境下也是需要进行处理的。
所以实际上开发中的错误一般是依据出现的上下文，可能产生的影响，或者说是各种处理方案的性价比来决定处理方案。
具体到你的例子，如果这个处理放在用户输入部分。即使你事先准备了各种提醒，那也架不住用户一不小心做了错误的输入。而且这种时候你不做处理那么程序可能会 crash ，用户体验会非常糟糕，那么最好是预先阻止掉各种意外的输入。如果你的处理只是一个内部调用的子函数，而且你已经和调用方约定好了输入只能是数字，那么再出现问题一般就是由调用方进行处理了。
我的做法：
用户输入类的，需要检查并给出友好提示。
如果是其他函数调用提供的参数，那么做一次强制转换，失败了不管，异常直接抛出去，由调用方处理。
如果是类似 https://www.v2ex.com/t/355154 里面的 355154 ，理论合法用户不会出现非数字的情况，这种直接同函数调用，直接抛异常。但是别忘了设置整站的 500 页面及错误日志。
作为开放出去的公用库，只要不是强类型，都建议判断
。
另外，另一种思路是如果产生了这种异常分支，不处理这个分支对整个工程的影响，拿正文举例：
- 如果不处理的结果是输出不满足输入结果需要，那么可以不处理，因为输入结果就是错误的
- 如果不处理的结果是抛异常或者 Crash ，那么再怎么样都要处理，防止出现“你这个函数写的容错性怎么这么差”的攻击机会
射飞镖的时候射中盘上任意一点概率都是 0 ，因为点 /面=0 ，但是只要射中了概率为 0 的事情就发生了，所以概率为 0 不是不可能发生。
对于用户的输入，即便用户完全不可能输入一个值，也要防止测试给你一个意外输入。总之原则上就是考虑所有可能。
保证程序的健壮性是很有必要的，因为你想不到的情况太多了
很多年前刚参加工作在一公司，软件发布前经过整个部门的轮番测试觉得已经不错了然后就发出去，结果短短几天用户反馈的 bug 达到 200 多个，当时测试跑过来说这个事我就惊呆了
莫非定律， Anything that can go wrong, will go wrong.
https://zh.wikipedia.org/wiki/%E6%91%A9%E8%8F%B2%E5%AE%9A%E7%90%86
