I feel that I understand a little about exception handling, which was a mystery when I was learning Java. If there is a learner who says, "The merit of handling exceptions is a mystery," I hope it will be useful as an example of how exception handling can be used.
In the process of making this program, I learned about exception handling. Language: Python3 Summary: Automatically monitor the virtual currency rate of Zaif Library: GitHub --techbureau / zaifapi (Thank you)
What I did is the same as looking at Zaif's official website. Just connect to Zaif via api and bring the currency rate information.
# -*- coding: utf-8 -*-
from zaifapi import ZaifPublicApi
zaif = ZaifPublicApi()
#Repeat 10 times
for i in range(10):
while (1):
err = False
try:
askBJ = zaif.depth('btc_jpy')['asks'][0][0]
askMJ = zaif.depth('mona_jpy')['asks'][0][0]
askMB = zaif.depth('mona_btc')['asks'][0][0]
bidBJ = zaif.depth('btc_jpy')['bids'][0][0]
bidMJ = zaif.depth('mona_jpy')['bids'][0][0]
bidMB = zaif.depth('mona_btc')['bids'][0][0]
except:
err = True
print('except')
if (err == False):
break
print(askBJ, end=', ')
print(askMJ, end=', ')
print(askMB, end=', ')
print(bidBJ, end=', ')
print(bidMJ, end=', ')
print(bidMB)
If a connection error occurs while processing in the try of the above program, the exception occurrence is detected and the processing in except is performed, and the try is repeated without getting out of the loop. In other words, "If you make a connection error, connect again" is repeated until the connection is successful.
From my point of view, these three are the good points of exception handling.
It is a biased view, but if you enclose the part where the exception occurs in try, it will not fall even if you pass (do nothing) with except. Ignored exceptions spread and cause an error in another place ... It will eventually fall, but with the above program, only a connection error will occur, so it will hold on.
I didn't know that in the old days, so I seriously thought of the exception as "a mysterious devil who relentlessly tries to drop the program."
[2018/2/5 postscript] It seems that there was a similar thing
Isn't SIer's subcontract developer too low? Don't understand what frameworks and libraries are doing ~ Omitted ~ These people typically don't understand "exceptions" at all. I don't know what it's for, and I'm only aware of things that interfere with my coding process.
try {
...
}catch(Exception e) {
return false;
}
You can write this kind of code to squeeze the error information.
This is certainly the case with my example, and I can't help because the countermeasures are "to make it absent."
To make an excuse, in my case it's OK if I reconnect, so I think it's still better.
In short, except through in the sense that "I want you to reconnect silently, but don't fall down one by one."
Of course, if you do not take the exception contents, you will not be able to find exceptions such as "Actually the API key is different" or "There is no such currency pair", so it will be out in the long run.
How to write exception handling that is troublesome for operators When an error occurs in the system, the operator looks at the log output from the program and identifies the cause. Exception handling is important at this time. _ With proper exception handling, it will be easier to identify the cause. _
Even in this program, I was suffering from the error Exception: return status code is 504 for a while before it was completed. Actually, at this point, I was told that the problem was a 504 error, so I finally arrived at "If you don't stop trying to connect until it passes".
If this is not an exception and it says "variable type is different" _ Why is the type different? Debug → Why is there no problem orz → If you turn it for a while, the same error sometimes occurs → The received data is out of order in the communication part, is this the type different? _
I finally understood the cause, and further _ Why are there times when it's normal and times when it's crazy? → It seems to happen regularly → Your side? The other party? → Is the server on the other side out of order? _
I feel like I notice the 504 error for the first time here (the example may be bad).
The exception is that it skips such a process and immediately tells you "I got a 504 error".
If you use exception handling, you can treat "the same problem at the root" as the same exception regardless of the details. Even if you try to pass the str type to the int type or vice versa, the problem that the variable types are different is the same, so even if you do not write two if statements, it will be summarized in TypeError as an exception (the example may be bad) unknown).
If you extend this, you can write a push like "If there is a problem, an exception will occur. If an exception occurs, exception handling will be all through!"
In the library used this time, there is a section that intentionally treats it as an exception when a strange value is detected (I think that the 504 error is the case). It looks a little nice because it looks like an efficient mechanism that the user does not have to worry about the details.
Recommended Posts