協(xié)程中提到的異步指的是兩個函數(shù)一起運(yùn)行，各個函數(shù)運(yùn)行到哪里cpu會中斷是不一定的。

---------------------------------------------------------------------------------------

協(xié)程能執(zhí)行成百上千個

協(xié)程就是并發(fā)的一種
并發(fā)不是并行,一個協(xié)程被阻塞，換其他協(xié)程繼續(xù)上
等待一個結(jié)束另一個在啟動的都是單線程
雖然不用gevent（畢竟python有自帶asyncio）不過異步concurrent的原理都差不多
gevent應(yīng)該是只有一個event loop再跑。然后切換的是任務(wù)gevent做了monkey patch（例如python2沒有async sleep這類的支持）
gevent做了monkey patch（例如python2沒有async sleep這類的支持）
至于系統(tǒng)看到的線程。那個一直都只有一個。因為python線程是自己做。不是os。所以系統(tǒng)線程數(shù)量跟gevent無關(guān)（如果看python自己提供的thread count。看到的是一個）
gevent，greenlet跟asyncio這些是指給你（用戶）決定什么時候切換。而線程則是python的runtime自己做。并且線程需要stack。這類的異步task則不用
cpu并行你無論開多少個線程實際上都只有一個線程在跑
多進(jìn)程：很吃cpu的代碼
io密集 訪問網(wǎng)站，
CPU密集 大量計算的
多線程：io等待。但是同時運(yùn)行線程在百來個之內(nèi)（小1-2千也可以，看具體）
協(xié)程是什么密集的呢？
異步io（async）io等待。可以做上萬task“同時”
python3的話。自己有帶asyncio模塊。就不用去使用第三方庫完成。python2的話。還是要gevent，greenlet，stackless這類的去實現(xiàn)
跑的是一個”event loop”
go不同。go自身的concurrent就是go routine
go routine 設(shè)計上就是asyncio這樣的（go自身實現(xiàn)的）
所以go很簡單： go 函數(shù) 就可以了
大多數(shù)情況下：多進(jìn)程+多線程/異步Io（協(xié)程）就夠了
換個說法：如果你需要多進(jìn)程+多線程或者異步。那么一般來說。你不用問這些問題的。如果你問這些問題。說明你并不需要用那樣的架構(gòu)
python的進(jìn)程并不能直接設(shè)定cpu affinity。所以是否一個進(jìn)程一個core沒法保證的
如果是linux系統(tǒng)。可以通過cgroups外圍形式來設(shè)定（開啟進(jìn)程后。在os設(shè)定這個進(jìn)程跑哪個core）
其他系統(tǒng)不知道。core的分配要看os、
進(jìn)程是否保持跟core一致還是多還是少是根據(jù)你需要而定的
多進(jìn)程也不一定都是跟運(yùn)算有關(guān)
進(jìn)程是獨(dú)立的。換句話說。一個進(jìn)程掛了，其他的進(jìn)程不影響。主進(jìn)程不影響
所以設(shè)計的時候。也有些是為了穩(wěn)定而采用多進(jìn)程的
例如你跑一個服務(wù)。你是要長期跑的。你擔(dān)心有內(nèi)存泄漏，擔(dān)心服務(wù)異常終止等待。那么一般就是主程序fork自進(jìn)程初開。主進(jìn)程做為watchdog。守護(hù)你的自進(jìn)程（并且負(fù)責(zé)重啟等等）
100個建議你直接thread吧
1000個的話。根據(jù)需要可能選擇攜程或者線程。100個基本不用想。直接thread多簡單（異步代碼會麻煩的多。尤其是異常處理部分，跟callback帶callback帶callback）




那如果代碼中多個“子進(jìn)程”的話，特定的一個協(xié)程有可能在不同的時間間隔被不同的子進(jìn)程來處理嗎？
不會。


也就是說，代碼設(shè)計的時候，某一個協(xié)程一定是“歸屬于”特定的進(jìn)程來執(zhí)行其返回的結(jié)果的
除非你自己做一個scheduler。把你的線程/攜程移到另外一個進(jìn)程里面（我不確定是否能真的做出來。不過簡單的demo應(yīng)該可以）






進(jìn)程就好像你的一個python腳本 你可以寫兩個文件。運(yùn)行python 文件名。然后兩個文件內(nèi)的代碼隨機(jī)跑在某個python（這里指的是終端上運(yùn)行的python pid）上嗎？
通信是信息傳遞。運(yùn)行就不是信息了。并不是說你把線程/攜程直接pickle起來另外一個進(jìn)程直接unpack讀回去就可以
我建議你可以找找進(jìn)程跟線程的基礎(chǔ)書看看。那個會講的比較全面。也比較正確
看過進(jìn)程線程之后。可以看看異步IO的東西。因為看過之后你大概就有個概念了。你可以看成：python的thread其實就是python自身維護(hù)了一個“thread-loop”
隨意python才有線程不能跨核的問題。因為系統(tǒng)（os）看到的只有一個線程而已
python在這個thread-loop中切換在不同的“thread”里面。你使用。就有了“線程”的感覺了




但是python的這個thread-loop是你沒法控制的（什么時候等待，什么時候切換）等等。這些都是python自身在運(yùn)行的時候決定
每個程序（其實嚴(yán)格的說包括進(jìn)程）內(nèi)核看到的都是個“線程”
例如c++你開10個線程。os看到的就是10個線程。所以os可以幫你放在不同cpu執(zhí)行（效率）
因為c++直接用pthread來做。而python的話。os能看到的只是“python”自身。跟你都沒關(guān)系。是你那個叫做python的指令




你的代碼都是在“python”里面。python來處理在做的。對于os來說。跟notepad沒有區(qū)別


但是python雖然不能直接給你pthread來做線程。但是在自身pyyhon中。也是用一樣的機(jī)制來架構(gòu)線程的




我：
python的線程沒法跨核，所以被吐槽了
多線程是為了榨干單獨(dú)一個核的性能
多進(jìn)程是榨干整個cpu的性能






所以你會有stack size，會有thread的各種屬性（用起來感覺跟線程一樣）
多線程一般不是為了吃cpu的（哥哥語言都是）主要是避免一些緩慢的等待。例如IO（硬盤讀區(qū)。網(wǎng)絡(luò)讀取等等）
如果吃cpu。單線程單進(jìn)程。鎖定core（這樣os不會幫你跳去其他core）可以把一個core的資源吃光






而異步（asyncio）跟線程最大的區(qū)別是。你自己決定。什么時候把使用權(quán)給出去
例如你一個代碼有5行。跑線程。你不知道在哪行。python就決定。你這個線程使用的cpu夠了。換下一個來
所以這五行中任意一行。都可能做為thread的切換點
asyncio則是把loop交給你（用戶）手里了
你可以決定。我這5行代碼。只有運(yùn)行到第三行的時候。才會切換出去
這樣。你1運(yùn)行了1一定會運(yùn)行2然后才出去
2.x沒有內(nèi)置的異步。一般用gevent，greenlet，stackless這類的做
因為你自己做的event，你并沒有stack
不像thread。python需要一個標(biāo)準(zhǔn)的stack（記得最小32k）
所以你的性能會好很多。同時，你只有“收到切換”的時候才會切換。就不需要thread那么復(fù)雜的scheduler來管理。一般來說。一個系統(tǒng)開1-2千個thread就差不多了。你可以花點功夫。做5-6千個（可以開啟，可以跑。但是性能就很不好了）而asyncio做event loop的話。可以輕松做上萬
python中比較出名的兩個：twisted 跟 tornado


看了下文檔。是32k。沒記錯
threading.stack_size([size])
Return the thread stack size used when creating new threads. The optional size argument specifies the stack size to be used for subsequently created threads, and must be 0 (use platform or configured default) or a positive integer value of at least 32,768 (32 KiB). I
threading模塊文檔
tornado是web服務(wù)。是“性能比較好”的web服務(wù)
性能的來源就在于他們是用asyncio來做的。而不是thread
所以也有很多人。拿tornado代碼過來。并不是跑服務(wù)。import之后。就用他們的async部分庫（python2自己是沒有asyncio的）
twisted的async庫有點類似node.js。是以defer這樣的形式來做
node.js之所以性能好。因為人家是async架構(gòu)
go之所以很多人喜歡。也是因為是async架構(gòu)（另外使用比較簡單）
python之所以很多人吐槽。不就是GIL（thread不能跨核）跟沒有異步嘛
python3帶了asyncio。甚至event loop都允許掛自己的（或者第三方）
uvloop這個項目。至少他們自稱（自己公布的）測試數(shù)據(jù)。python3自帶的asyncio+uvloop可以達(dá)到基本接近go的性能（簡單的異步處理）
雖然說不可全信。而且實際應(yīng)用的話代碼會復(fù)雜很多，不可能保持那個性能。但是已經(jīng)是很厲害了
GIl很好拆除呀
網(wǎng)上很多教程的
好想就3-5行代碼。注釋掉就好了
不過為什么要移除呢？
你真的需要夸核。直接用cython就好了。可以直接lift gil的
如果你程序架構(gòu)沒錯（python屬于高級語言，很多東西做起來很簡單）gil不是問題
不用混編。不過允許你把python直接編譯成二進(jìn)制可執(zhí)行。允許你混編
另外python不是有芹菜嘛
其實就算python自己帶的multiprocessing模塊。manager也是可以跨越機(jī)器的
有幾個語言自帶的庫。可以讓我寫代碼直接分散到幾百個電腦去的？
所以gil其實沒什么好抱怨的
業(yè)余中大多數(shù)情況下：多線程優(yōu)越于異步IO
就好像匯編語言性能好。也沒說人人都在用
就是非專業(yè)很多人自己理解力有限
寫出來的東西穩(wěn)定，性能什么的就都有限
省事的多的多多多的多了
寫代碼不是你看博客看書例子那么簡單的
另外一個也算在這個范圍的東西。就是event driven了
例如python的select模塊
select，pool，epool，kqueue這些
select跟pool應(yīng)該是各個平臺都有支持。epoll只有l(wèi)inux有kqueue只有bsd
unix好像還有一個什么。不記得了。文檔應(yīng)該有寫


https://docs.python.org/3/library/select.html
這個python2根3都支持




不過3支持一個新的selectors很好用。這個自動使用select下面的最適合你當(dāng)前os的方法
也就是說。不用自己寫代碼分別區(qū)分處理linux，osx，windows的區(qū)別
例如select.epool或者kqueue也是可以直接單線程上輕松10k鏈接的東西
select.select是比較老的。有1024的file descriptor的限制


但是我概念上就不理解，如果代碼本身已經(jīng)寫成多進(jìn)程，那么flask中的這個多進(jìn)程選項processes=N是不是就沒用了呢？？？


我就用過一次flask（一共就一天時間。為了寫個rest server）
run(host=None, port=None, debug=None, **options)
options – the options to be forwarded to the underlying Werkzeug server. See werkzeug.serving.run_simple() for more information.
所以還不是flask直接用的
我不是做開發(fā)的。就寫過那么一次web
processes – if greater than 1 then handle each request in a new process up to this maximum number of concurrent processes.
http://werkzeug.pocoo.org/docs/0.14/serving/#werkzeug.serving.run_simple
等于你的route是丟進(jìn)一個process pool里面的
run的時候process設(shè)定的是你的pool的大小




你開pool的話 不運(yùn)行開始的時候就init了
然后東西都給pool中空閑的資源去處理
處理完了就處理下一個
可以看multiprocessing中的pool那段
flask是做上層的。下面處理http自身的是另外的代碼
flask是邏輯
http自身的request是后面的另外那個用。所以process是丟到那邊去的




不能直觀看到協(xié)程? 內(nèi)部有協(xié)程隊列保存協(xié)程狀態(tài)




總結(jié)下：系統(tǒng)只能看到python的主線程，看不到python開的子線程
協(xié)程歸進(jìn)程來管，線程不能跨核，協(xié)程也不能。










大佬 22:07:33
因為我們公司開發(fā)比我厲害的太多了
大佬 22:07:57
我這種水平（甚至測試?yán)锩婧芏啾任液玫?#xff09;都還不夠開發(fā)的標(biāo)準(zhǔn)
大佬 22:09:37
你看flask官網(wǎng)的第一句話：Flask is a microframework for Python based on Werkzeug,?
大佬 22:10:03
run里面的process是直接傳給werkzeug的
大佬 22:10:55
看文檔介紹。感覺就是個pool設(shè)定process的數(shù)量。具體的實際情況。翻一下werkzeug代碼就知道了
太古時代的小鯉魚 22:13:23
好的，謝謝您~
太古時代的小鯉魚 22:13:32
我正在整理記錄您的話~




好奇，就看了一下flask的run里面的processes這個參數(shù)


大佬 22:33:36
flask的run是把參數(shù)直接傳遞給?
werkzeug.serving.run_simple?
run_simple用這個參數(shù)叫了make_serve
make_server說 ：
elif processes > 1:?
? ? return ForkingWSGIServer(host, port, app, processes, request_handler, passthrough_errors, ssl_context, fd=fd)


所以這個參數(shù)又給了ForkingWSGIServer


ForkingWSGIServer繼承了兩個class
werkzeug.serving： https://github.com/pallets/werkzeug/blob/master/werkzeug/serving.py


大佬 22:33:43
ForkingWSGIServer(ForkingMixIn, BaseWSGIServer)
? ? self.max_children = processes
大佬 22:34:03
ForkingMixIn又是什么？
if can_fork:
? ? ForkingMixIn = socketserver.ForkingMixIn
else:
? ? class ForkingMixIn(object):
? ? ? ? pass


大佬 22:34:16
搞了半天是跳去了python內(nèi)置的socketserver.ForkingMixin了


大佬 22:34:38
回到python內(nèi)置部分（socketserver是python自帶的）
https://github.com/python/cpython/blob/master/Lib/socketserver.py




大佬 22:34:47
class ForkingMixIn:
? ? ? ? """Mix-in class to handle each request in a new process."""
? ? ? ? timeout = 300
? ? ? ? active_children = None
? ? ? ? max_children = 40


大佬 22:34:53
while len(self.active_children) >= self.max_children:?
? ? try:
? ? ? ? pid, _ = os.waitpid(-1, 0)
? ? ? ? self.active_children.discard(pid)
? ? except ChildProcessError:
? ? ? ? # we don't have any children, we're done
? ? ? ? self.active_children.clear()
? ? ? ? except OSError:
? ? ? ? ? ? break


大佬 22:35:20
就是直接os.fork出去的子進(jìn)程做處理


大佬 22:35:30
看完了，就沒什么神秘的了


大佬 22:36:40
def process_request(self, request, client_address):
? ? ? ? ? ? """Fork a new subprocess to process the request."""
? ? ? ? ? ? pid = os.fork()
? ? ? ? ? ? if pid:


大佬 22:37:03
所以就是在處理請求的時候，創(chuàng)建一個新的進(jìn)程來處理


大佬 22:37:42
直到達(dá)到了你給的最大數(shù)字


大佬 22:38:01
python自己內(nèi)定的是開40個進(jìn)程


大佬 22:38:28
不算是proess pool，因為pool是把process開起來了之后，丟task過去。這個是task來了，再開


大佬 22:38:38
你平時不怎么看代碼的關(guān)系吧


太古時代的小鯉魚 22:39:14
是的，直接拿來用了
太古時代的小鯉魚 22:39:33
?
大佬 22:40:12
你上班平時不用第三方庫？


太古時代的小鯉魚 22:40:52
分不清哪個是第三方庫~


太古時代的小鯉魚 22:40:55
都沒太在意


太古時代的小鯉魚 22:41:03
雖然上次有人說過一次




就是你import的東西不是python自帶的


太古時代的小鯉魚 22:41:13
但是依然沒有留下深刻的音箱
太古時代的小鯉魚 22:41:18
用啊




大佬 22:41:21
因為python自帶的都比較好，文檔一定齊全
太古時代的小鯉魚 22:41:35
可是吧


大佬 22:41:35
如果是其他的，就很難說了，文檔不好的時候，都是需要翻看源碼的
太古時代的小鯉魚 22:41:44
源碼這東西
太古時代的小鯉魚 22:41:51
沒注釋真的看起來挺煩的


大佬 22:42:20
不覺得，python的源碼覺得真的很容易看


大佬 22:42:29
其他語言，沒有遇到比這個更容易看的
太古時代的小鯉魚 22:42:37
好吧，大神~?


大佬 22:43:56
一般都是這樣的
太古時代的小鯉魚 22:44:08
? ?
大佬 22:44:17
第三方庫，有些可能基本沒有文檔，注釋不怎么寫（請問你寫代碼會寫很多注釋給別人看嗎？）
太古時代的小鯉魚 22:44:31
我都寫蠻詳細(xì)的注釋


太古時代的小鯉魚 22:44:34
不過吧
太古時代的小鯉魚 22:44:36
沒人會看


太古時代的小鯉魚 22:44:41
因為只有我自己一個人寫


太古時代的小鯉魚 22:44:47
python


太古時代的小鯉魚 22:44:52
沒人會去改動他


太古時代的小鯉魚 22:44:57
所以。。。。也是蠻尷尬的


大佬 22:45:26
所以都是看代碼。不過python代碼規(guī)則比較嚴(yán)謹(jǐn)，一般一種東西也只有一兩個做法，所以很容易理解（不像ruby，如果用python的眼光看，那就是一堆monkey patch，簡直沒法看）
大佬 22:45:43
省事


大佬 22:46:03
不像我們整天都爭著搶提交


大佬：
設(shè)計模式
算法
架構(gòu)
大佬 23:22:14
代碼架構(gòu)
代碼嚴(yán)謹(jǐn)程度
代碼質(zhì)量：不夠。如果寫個自己的服務(wù)，一般保證幾個星期連續(xù)運(yùn)行沒有問題。幾個月或者一年的那種？不敢給任何保證（現(xiàn)在有個我寫的東西，還是平均幾個月就掛一次，我都不知道哪里的問題）
大佬 23:24:45
知道的東西：少。畢竟不是做這個的。公司要求用狀態(tài)機(jī)，我才開始看什么是狀態(tài)機(jī)。
公司要求用RX了（ReactiveX）我才看是學(xué)什么是RX




try except可以防止掛嗎


大佬 23:36:10
try:
? ? xxxx
except Exception as error:
? ? yyy
這樣的代碼可以后，一般整個項目只能有一個（總?cè)肟?#xff09;用來處理所有的未知錯誤
太古時代的小鯉魚 23:36:48
不能一邊改一邊上線嗎？
太古時代的小鯉魚 23:37:02
感覺您那邊應(yīng)該是屬于開發(fā)-測試流程很嚴(yán)謹(jǐn)?shù)哪欠N
太古時代的小鯉魚 23:37:14
我之前待的小公司直接改完bug沒怎么測試就上了
太古時代的小鯉魚 23:37:19
雙擊查看原圖
大佬 23:38:33
一般的代碼寫法：
try:
? ? 你要做的事情
except ValueError as error:
? ? 處理 ValueError?
except IOError as error:
? ? 處理 IOError
except OSError as error:
? ? 處理 OSError
? ? raise #丟回上面的stack
except AttributeError as error:
? ? 處理 AttributeError
? ? raise ApplicationError(error) #處理一個error，然后raise成其他的
大佬 23:40:07
我在外企
太古時代的小鯉魚 23:40:10
我的想法是：不能是出錯的直接跳過，先繼續(xù)跑后面的任務(wù)嗎
太古時代的小鯉魚 23:40:12
？
大佬 23:40:15
洋人要求比較多
太古時代的小鯉魚 23:40:18
我知道，您提過
大佬 23:40:27
例如代碼沒有過系統(tǒng)的測試。都無法提交的
太古時代的小鯉魚 23:40:35
這樣。。。。
太古時代的小鯉魚 23:40:44
不容易
大佬 23:40:50
try的作用是“抓到你認(rèn)為會出現(xiàn)的錯誤”
大佬 23:41:06
如果你try之后的except不寫原因。那么很簡單，你自己都不知道你代碼哪里會錯
太古時代的小鯉魚 23:41:18
對啊
大佬 23:41:43
換句話說，自己寫的，自己都不懂的代碼，那么誰應(yīng)該懂？誰應(yīng)該看？
太古時代的小鯉魚 23:41:49
就這么搞啊，如果我知道哪里會出錯，我直接就改過來了呀，就不用try except了啊
太古時代的小鯉魚 23:41:50
可是
太古時代的小鯉魚 23:41:56
他們之前告訴我的是：
太古時代的小鯉魚 23:42:11
使用try except是在自己不知道哪里會出錯的情況下使用的，他們強(qiáng)調(diào)說，防止掛掉
大佬 23:42:16
所以那種except拿到所有錯誤（Exception）的，一個項目只有最外面的那個大出口的 __name__ == '__main__' 下面可以出現(xiàn)一次
太古時代的小鯉魚 23:42:35
感覺您講的比他們說的嚴(yán)謹(jǐn)多了
大佬 23:42:40
如果你都不知道出的什么錯？你怎么防止掛掉？
大佬 23:42:45
你只是“希望”不會掛掉
太古時代的小鯉魚 23:42:46
直接pass
太古時代的小鯉魚 23:42:59
他們說，跑到except那里，可以直接pass
太古時代的小鯉魚 23:43:10
繼續(xù)執(zhí)行下一輪循環(huán)或者之后的代碼
太古時代的小鯉魚 23:43:32
那也就是說：您那邊的代碼都經(jīng)過系統(tǒng)測試，不怕掛，那么也就是不需要try except了？
23:44:01
你撤回了一條消息
23:44:04
你撤回了一條消息
大佬 23:44:05
例如系統(tǒng)給你一個MemoryError （因為你沒有足夠的內(nèi)存了）難道pass系統(tǒng)就自動增加內(nèi)存了？
大佬 23:44:27
需要很多的try except，但是是你自己知道的東西，自己要去處理
太古時代的小鯉魚 23:44:51
那想不到的error怎么辦
太古時代的小鯉魚 23:45:06
那種想不到的會導(dǎo)致系統(tǒng)掛掉的error
太古時代的小鯉魚 23:45:26
之前群里說用try except，聽您這么一講，其實他們是在濫用了
大佬 23:45:42
例如我寫個function，接受一個變量，要求這個變量是 JSON 的字符串，然后處理
太古時代的小鯉魚 23:46:25
我崩掉過，就是網(wǎng)絡(luò)斷網(wǎng)了
太古時代的小鯉魚 23:46:31
直接崩掉
太古時代的小鯉魚 23:46:34
沒考慮到當(dāng)時
太古時代的小鯉魚 23:47:19
您早點休息吧~改天我再請教您~
太古時代的小鯉魚 23:47:33
太晚了，真不好意思浪費(fèi)您這么多時間~
太古時代的小鯉魚 23:47:42
明天您還要上班呢~


大佬 23:25:20
這些很多的東西加在一起，就是說離開發(fā)還是很大的距離的。又何必為難自己去做開發(fā)呢？
太古時代的小鯉魚 23:32:07
不是說。。。
太古時代的小鯉魚 23:32:14
try except可以防止掛嗎
太古時代的小鯉魚 23:32:18
出問題可以繼續(xù)跑
太古時代的小鯉魚 23:32:33
設(shè)計模式我聽說web這塊用得比較多
太古時代的小鯉魚 23:32:40
但是面試官的gitlab我看了
太古時代的小鯉魚 23:32:46
他其實主要是java
太古時代的小鯉魚 23:32:53
python這塊他沒有用過設(shè)計模式
太古時代的小鯉魚 23:33:06
狀態(tài)機(jī)是離散數(shù)學(xué)里的
太古時代的小鯉魚 23:33:14
其實我一開始接觸狀態(tài)機(jī)是在數(shù)字電路里的
太古時代的小鯉魚 23:33:53
代碼架構(gòu)我也不會
太古時代的小鯉魚 23:34:12
算法的話，不去做AI，音頻和圖像，那么基本是用不到的吧
太古時代的小鯉魚 23:34:17
哎
太古時代的小鯉魚 23:34:19
早點休息
太古時代的小鯉魚 23:34:22
謝謝您了
太古時代的小鯉魚 23:34:25
受益匪淺~
大佬 23:36:10
try:
? ? xxxx
except Exception as error:
? ? yyy
這樣的代碼可以后，一般整個項目只能有一個（總?cè)肟?#xff09;用來處理所有的未知錯誤
太古時代的小鯉魚 23:36:48
不能一邊改一邊上線嗎？
太古時代的小鯉魚 23:37:02
感覺您那邊應(yīng)該是屬于開發(fā)-測試流程很嚴(yán)謹(jǐn)?shù)哪欠N
太古時代的小鯉魚 23:37:14
我之前待的小公司直接改完bug沒怎么測試就上了
太古時代的小鯉魚 23:37:19
?
大佬 23:38:33
一般的代碼寫法：
try:
? ? 你要做的事情
except ValueError as error:
? ? 處理 ValueError?
except IOError as error:
? ? 處理 IOError
except OSError as error:
? ? 處理 OSError
? ? raise #丟回上面的stack
except AttributeError as error:
? ? 處理 AttributeError
? ? raise ApplicationError(error) #處理一個error，然后raise成其他的
大佬 23:40:07
我在外企
太古時代的小鯉魚 23:40:10
我的想法是：不能是出錯的直接跳過，先繼續(xù)跑后面的任務(wù)嗎
太古時代的小鯉魚 23:40:12
？
大佬 23:40:15
洋人要求比較多
太古時代的小鯉魚 23:40:18
我知道，您提過
大佬 23:40:27
例如代碼沒有過系統(tǒng)的測試。都無法提交的
太古時代的小鯉魚 23:40:35
這樣。。。。
太古時代的小鯉魚 23:40:44
不容易
大佬 23:40:50
try的作用是“抓到你認(rèn)為會出現(xiàn)的錯誤”
大佬 23:41:06
如果你try之后的except不寫原因。那么很簡單，你自己都不知道你代碼哪里會錯
太古時代的小鯉魚 23:41:18
對啊
大佬 23:41:43
換句話說，自己寫的，自己都不懂的代碼，那么誰應(yīng)該懂？誰應(yīng)該看？
太古時代的小鯉魚 23:41:49
就這么搞啊，如果我知道哪里會出錯，我直接就改過來了呀，就不用try except了啊
太古時代的小鯉魚 23:41:50
可是
太古時代的小鯉魚 23:41:56
他們之前告訴我的是：
太古時代的小鯉魚 23:42:11
使用try except是在自己不知道哪里會出錯的情況下使用的，他們強(qiáng)調(diào)說，防止掛掉
大佬 23:42:16
所以那種except拿到所有錯誤（Exception）的，一個項目只有最外面的那個大出口的 __name__ == '__main__' 下面可以出現(xiàn)一次
太古時代的小鯉魚 23:42:35
感覺您講的比他們說的嚴(yán)謹(jǐn)多了
大佬 23:42:40
如果你都不知道出的什么錯？你怎么防止掛掉？
大佬 23:42:45
你只是“希望”不會掛掉
太古時代的小鯉魚 23:42:46
直接pass
太古時代的小鯉魚 23:42:59
他們說，跑到except那里，可以直接pass
太古時代的小鯉魚 23:43:10
繼續(xù)執(zhí)行下一輪循環(huán)或者之后的代碼
太古時代的小鯉魚 23:43:32
那也就是說：您那邊的代碼都經(jīng)過系統(tǒng)測試，不怕掛，那么也就是不需要try except了？
23:44:01你撤回了一條消息
23:44:04你撤回了一條消息
大佬 23:44:05
例如系統(tǒng)給你一個MemoryError （因為你沒有足夠的內(nèi)存了）難道pass系統(tǒng)就自動增加內(nèi)存了？
大佬 23:44:27
需要很多的try except，但是是你自己知道的東西，自己要去處理
太古時代的小鯉魚 23:44:51
那想不到的error怎么辦
太古時代的小鯉魚 23:45:06
那種想不到的會導(dǎo)致系統(tǒng)掛掉的error
太古時代的小鯉魚 23:45:26
之前群里說用try except，聽您這么一講，其實他們是在濫用了
大佬 23:45:42
例如我寫個function，接受一個變量，要求這個變量是 JSON 的字符串，然后處理




大佬 0:13:07
只好做OOM kill
大佬 0:13:14
進(jìn)程？如果consumer掛了，不是進(jìn)程了
大佬 0:13:14
是你整個OS都掛了
大佬 0:13:14
因為producer不停的在queue里面丟東西，最后OS






































































?

總結(jié)

以上是生活随笔為你收集整理的大佬对协程以及try except的详细解释的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。