推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
这是一个创建于 1688 天前的主题，其中的信息可能已经有所发展或是发生改变。
新手，务笑！
我知道 try 使用范围是在你觉得可能出错的地方使用，但实际开发中，哪些算是呢？
常常忘记使用 try （除了那些自己设计的异常类，需要手动捕获的）
我知道的有涉及到文件打开读写，数据库的读写
还有哪些现实开发中需要使用 try 的地方吗？
 |
1
knightdf 2021-03-17 17:27:11 +08:00
就好比你现在上网，你怎么知道一定能打开网页呢？你得 try 吧，万一你网线断了，你网络不通，你网太慢打开超时了， 或者你打开的网页内容不对，看不懂，这不都是可能出的错么
|
 |
2
acmore 2021-03-17 17:34:29 +08:00
例如网络请求，数据解析，格式转换等方面都常用。
核心不在于找到错误而是在于： 1. 解决错误（ retry, bypass, default value ...）使程序回到正常流程； 2. 尽早通知用户发生了需要人为介入处理的情况； |
 |
3
huijiewei 2021-03-17 17:39:15 +08:00  8
非自己可控的数据流
|
 |
4
zhaorunze 2021-03-17 17:48:46 +08:00 1
不是你写的代码都需要
|
 |
5
Orenoid 2021-03-17 18:20:10 +08:00 1
当你不希望不可控的错误一路上抛到程序最顶层的时候
|
 |
6
Pagliacii 2021-03-17 18:38:59 +08:00
当你需要调用代码，而又没有办法确保被调用的代码能正确执行时，就需要用捕获可能出现的异常。然后调用方再做相应的处理。
|
 |
7
MeteorCat 2021-03-17 18:40:16 +08:00 via Android
网络请求最明显，你永远不知道是断网还是 dns 出错或者啥奇奇怪怪的原因
|
 |
8
touchwithe 2021-03-17 18:44:01 +08:00 via iPhone
总结一下就是各种 io 操作，包括但不限于网络请求、文件读者、数据库 crud...
|
 |
9
ebingtel 2021-03-17 18:47:39 +08:00 1
1 、不想导致本 进 /线 /协 程挂掉的
2 、不想暴露底层错误细节的 |
 |
10
QBugHunter 2021-03-17 18:53:31 +08:00
try
openFile catch 要是这个文件不存在肿么办？要是这个文件没有权限肿么办？要是文件类型错误肿么办？ |
 |
11
darksword21 PRO 直接用 go
|
 |
12
no1xsyzy 2021-03-17 19:00:13 +08:00
调用不是你写的代码，并且不接受上抛的情况
|
 |
13
walpurgis 2021-03-17 19:18:50 +08:00
其实对于这类设计问题最好是去研究为什么这样设计，解决了什么问题，而不是记住什么时候用，可以搜一下没有异常处理的语言是怎么处理的
|
 |
14
xuanbg 2021-03-17 19:59:31 +08:00
不希望抛出异常的时候
|
 |
15
maloneleo88 2021-03-17 21:10:05 +08:00
写完要试运行啊，肯定 BUG 多多
不可控的地方都要用。某些时候不仅用一次。 要 try: try: try: except: except: except: 这东西永远无法预估，就是一个不断解决问题的过程。 我学的过程就是，稀里糊涂写了几百行代码。所有函数全在一起，运行起来都要卡机（因为用 pycharm 打开的）。然后就是 bug 重重，然后不断的改，不会的就出来问，好心人还是很多的。（过嘴瘾的也有，不理就好了。） 然后就是不断的改，修，补，一直到最后，学着把各个功能归类，分装到不同的模块，慢慢就有条理了。也理解了刚开始一直弄不明白的面对对象而非面对流程。 然后就舒服多了。主程序空壳一个，加一些基本的东西和注释。 各个模块有各个模块的作用，各个函数有各个函数的功能。 没什么 BUG 了，即使有，秒找出来。因为清晰了，有个宏观的概念了。也不用牵一发动全身了。 要俯视这件事情，不要置身其中。 我这段时间的学习经验。 先动手吧，真有问题再问，而不是预计会有什么问题。能预估到的问题都不是问题。 为一个目的而去做一件事，而不是把这件事看懂了，再去做。 因为永远都不能置身事外看懂内在。 |
 |
16
renmu123 2021-03-17 21:18:21 +08:00 via Android
Python 的 try 是非常轻量的操作，社区甚至推崇用 try 来代替一定的 if
|
|
17
maloneleo88 2021-03-17 21:20:11 +08:00
就算没有用到的地方，我也认为尽量把程序写进 try 里，保证其他部分的程序可以正常运行。。。我抓数据，基本用了无数个 try, 各种突发情况简直措不及防。 :DDDD
|
 |
18
pastgift 2021-03-17 21:22:13 +08:00 via iPhone
也有取深层 json 字段，但结构可能不正确的时候
try: data = j['a']['b']['c'] except KeyError as e: data = None if data is None: pass |
 |
19
WhiteDragon96 2021-03-17 21:26:58 +08:00
一般我会把所有的业务都写 try catch
|
 |
20
jzmws 2021-03-17 21:28:52 +08:00
外部的 , 不是主要业务流程 (失败了有补偿机制的)
|
 |
21
mumbler 2021-03-17 21:35:28 +08:00 via Android
无法预料的输入
|
 |
22
sudoy 2021-03-17 21:54:02 +08:00
楼上正解，无法预料输入的时候一般用 try
|
 |
23
ClericPy 2021-03-17 22:00:01 +08:00
必不必须我不知道, 遇到层层嵌套的函数或者条件, 普通的 return 或者 break 已经无法跳出去的时候, 我就直接自定义个 Exception 然后 raise 出去... 比如深层 retry
我就是这么骚气 |
 |
24
Variazioni 2021-03-18 07:33:22 +08:00
还是经验太少。。写个两年代码你自然就明白了。。。
|
 |
25
zm8m93Q1e5otOC69 2021-03-18 08:28:10 +08:00
@WhiteDragon96 慢的要死，try 有额外开销
|
 |
26
luckyc 2021-03-18 08:30:59 +08:00
知道可能会有出错的风险就 try
|
 |
28
ch2 2021-03-18 11:49:56 +08:00
当你的系统必须为不可靠的输入输出买单，而你又不知道到底会出现什么不靠谱的情况的时候
|
 |
29
cominghome 2021-03-18 16:59:38 +08:00
有两种情况，
1. 知道这里可能会出错，并且这个错误有办法处理，就针对性地 catch 起来 2. 不知道这里会不会出错，但是不希望错误扩散，就套一个大的 Exception 都抓起来 |
Select Language