投稿ありがとうございます。

> 最後のretrne Noneは不要だと思いました。

あってもなくても良いです。
明示的に None を返しているのは、「for 文内での return 文で処理が終わらない可能性もある」ということを明示するためです。

というかそもそも、ここと response.status_code が 200 ではない場合のところでは、何らかの例外を発生させるほうがよいです。

以下は一例ですが、こうして return 文 を raise 文で置き換えてみると、「最終行に何かあったほうが良い」ということが理解できるかと思います。

def get_current_unit_price(self):
    """ 現在の買取単価を調べる """
    url = f'{self.base_url}/info/csv/'
    response = requests.get(url)
    if response.status_code != 200:
        raise ValueError(f'サーバーからの応答が不正です: {response.status_code}')
    text_lines = response.text.splitlines()
    reader = csv.reader(text_lines, )
    for row in reader:
        if row[0] == self.type_name:
            return int(row[1])
    raise ValueError(f'{self.type_name}の情報が見つかりませんでした')

なお、この実装で raise 文ではなく return 文にしたのは、raise 文は次章まで講座で正式には紹介されていなかったからです。(ほとんどの受講生の方は、この動画あたりでは、クラスとインスタンスのことだけですでに脳みそがいっぱいかな、と思いまして...)

まずは、以上のとおりです。

2022/11/21 20:24

小川先生

ご回答くださいまて、ありがとうございます。

>明示的に None を返しているのは、「for 文内での return 文で処理が終わらない可能性もある」ということを明示するためです。
というかそもそも、ここと response.status_code が 200 ではない場合のところでは、何らかの例外を発生させるほうがよいです。

安直にresponse.status_codeが200以外だったら例外処理をする、という条件分岐があればよいと思ってました。
「for 文内での return 文で処理が終わらない可能性もある」場合について、念頭にいれておりませんでした。

堅牢なプログラムを構築する上で、実行時に発生するエラーをキャッチする、制御する仕組みを十分すぎるくらい考慮することが、大切なのだとあらためて思いました。

安易に考えていたので、大変勉強になりました。
ありがとうございます。

＞この動画あたりでは、クラスとインスタンスのことだけですでに脳みそがいっぱいかな、と思いまして...)
はい、私の脳みそはいっぱいいっぱいです。(;^_^A

2022/11/21 21:32

例外で処理してしまうことのメリットは、深いところで予定外のことが起きてしまったときのための処理を簡単に書けることです。

以下の sample1.py, sample2.py を比較してみましょう。

どちらも、呼び出しの流れは以下のとおりです。

[0] 大元の呼び出し (if __name__ == '__main__': 内)
↓
[1] get_price_string #内部で呼び出した関数の戻り値(JPYでの総額、数値)を文字列になおす
↓
[2] get_price_per_yen #内部で呼び出した関数の戻り値(USDでの総額、数値)を日本円になおす
↓
[3] get_stock_price #USDでの単価を元にして、総額を取得
↓
[4] Stock クラスのメソッド get_current_unit_price #USDでの単価を取得

違いは、Stock クラスのインスタンスメソッドで異常系の処理が起きたときの処理です。
sample1.py では、ValueError を返します。
sample2.py では、戻り値として None を返します。

sample1.py では、[4] で異常系の処理に進む場合の処理を書くのは簡単です。
[0] の大元での呼び出しで、 try ... except 文を加えておけばOK。
「こうすれば、穏やかでない処理結果になったとき、[1], [2], [3] でどうするか」といったことは一切考えずに済みます。

sample1.py

import requests
import csv


class Stock:
    def __init__(self, type_name, total_price, amount):
        self.type_name = type_name
        self.total_price = total_price
        self.amount = amount

    def get_current_unit_price(self):  # [4] USDでの価格を取得
        url = 'https://flask.pc5bai.com/stock/info/csv/'
        response = requests.get(url)
        if response.status_code != 200:
            raise ValueError(f'サーバーからの応答が不正です: {response.status_code}')
        text_lines = response.text.splitlines()
        reader = csv.reader(text_lines, )
        for row in reader:
            if row[0] == self.type_name:
                return int(row[1])
        raise ValueError(f'{self.type_name}の情報が見つかりませんでした')


def get_stock_price():  # [3] USDでの総額を取得
    amount = 3000
    ms = Stock("wikipedal", 600000, amount)
    current_unit_price = ms.get_current_unit_price()
    return current_unit_price * amount


def get_price_per_yen():  # [2] 1USD = 145円 として円に変換
    result_from_func_a = get_stock_price() * 145
    return result_from_func_a


def get_price_string():  # [1] 数値を受け取り、文字列を返す
    result_from_func_b = get_price_per_yen()
    return f'現在の資産総額は{result_from_func_b}円です'


if __name__ == '__main__':
    try:
        result_from_func_c = get_price_string()  # [0] 大元の呼び出し
    except ValueError as e:
        print(e)
    else:
        print(result_from_func_c)

sample2 では、そうはいきません。
[4] が None を返すので、 [3] は「None を受け取ったらどうする」といった条件分岐を必要とします。
[3] が返す値がおかしな場合に備えて、[2]でも条件分岐を必要とします。
[2] が返す値がおかしな場合に備えて、[1]でも条件分岐を必要とします。
...

ということで、異常終了しないで済むプログラムを書こうとするならば、以下のように煩雑なものになってしまいます。
しかも、さんざん煩雑な処理を書いたわりには、異常終了したときの情報として出力できるのは、「価格の取得に失敗しました」という文字列1パターンだけです。
sample1 では、status_code で異常検出した場合、csvを解析して所望のキーが見つからなかった場合で出力内容を変更できました。それに比べると、出力内容も残念です。

sample2.py

import requests
import csv


class Stock:
    def __init__(self, type_name, total_price, amount):
        self.type_name = type_name
        self.total_price = total_price
        self.amount = amount

    def get_current_unit_price(self):  # [4] USDでの価格を取得
        url = 'https://flask.pc5bai.com/stock/info/csv/'
        response = requests.get(url)
        if response.status_code != 200:
            return None
        text_lines = response.text.splitlines()
        reader = csv.reader(text_lines, )
        for row in reader:
            if row[0] == self.type_name:
                return int(row[1])
        return None


def get_stock_price():  # [3] USDでの総額を取得
    amount = 3000
    ms = Stock("wikipedal", 600000, amount)
    current_unit_price = ms.get_current_unit_price()
    if current_unit_price is None:
        return None
    return current_unit_price * amount


def get_price_per_yen():  # [2] 1USD = 145円 として円に変換
    result_from_func_a = get_stock_price()
    if result_from_func_a is None:
        return None
    return result_from_func_a* 145


def get_price_string():  # [1] 数値を受け取り、文字列を返す
    result_from_func_b = get_price_per_yen()
    if result_from_func_b is None:
        return None
    return f'現在の資産総額は{result_from_func_b}円です'


if __name__ == '__main__':
    result_from_func_c = get_price_string()  # [0] 大元の呼び出し
    if result_from_func_c is None:
        print("価格の取得に失敗しました")
    print(result_from_func_c)

ということで、冒頭に記載した結論に行き着きます。
例外で処理してしまうことのメリットは、深いところで予定外のことが起きてしまったときのための処理を簡単に書けることです。

2022/11/21 23:06

try ... except 文を使うことのメリットとして、内部で呼び出されたプログラム内の様々なタイミングで生じかねない種々のエラーを一箇所でハンドリングできるということも挙げられます。

以下の sample3.py では、 ValueError だけでなく、 requests.exceptions.ConnectionError もハンドリングするようにしました。
そのためにしたことは、sample1.py のプログラムで、同レベルの処理としてほんの2行を追加しただけです。
それですべてが済むのですから、簡単ですね。

さきほどのsample2のようなコードだと、 requests.exceptions.ConnectionError が生じた場合のハンドリングをどこでどう記述するか、かなり悩みそうです。(というか、要するに、設計が悪いです)

端末のwifiをオフにする等、手元のマシンをインターネットから切り離しから実行してみてください。

sample3.py

import requests
import csv


class Stock:
    def __init__(self, type_name, total_price, amount):
        self.type_name = type_name
        self.total_price = total_price
        self.amount = amount

    def get_current_unit_price(self):  # [4] USDでの価格を取得
        url = 'https://flask.pc5bai.com/stock/info/csv/'
        response = requests.get(url)
        if response.status_code != 200:
            raise ValueError(f'サーバーからの応答が不正です: {response.status_code}')
        text_lines = response.text.splitlines()
        reader = csv.reader(text_lines, )
        for row in reader:
            if row[0] == self.type_name:
                return int(row[1])
        raise ValueError(f'{self.type_name}の情報が見つかりませんでした')


def get_stock_price():  # [3] USDでの総額を取得
    amount = 3000
    ms = Stock("wikipedal", 600000, amount)
    current_unit_price = ms.get_current_unit_price()
    return current_unit_price * amount


def get_price_per_yen():  # [2] 1USD = 145円 として円に変換
    result_from_func_a = get_stock_price() * 145
    return result_from_func_a


def get_price_string():  # [1] 数値を受け取り、文字列を返す
    result_from_func_b = get_price_per_yen()
    return f'現在の資産総額は{result_from_func_b}円です'


if __name__ == '__main__':
    try:
        result_from_func_c = get_price_string()  # [0] 大元の呼び出し
    except ValueError as e:
        print(e)
    except requests.exceptions.ConnectionError as e:
        print(e)
    else:
        print(result_from_func_c)

2022/11/21 23:14

エラーハンドリングの大切さについて学ぶことができました。
クラスの講座の後に例外処理を勉強することになるのですが、この段階で勉強することができて、ありがたいと思いました。ありがとうございます。

通常、実行時にエラーが発生すると異常終了となってしまいます。
raise文は、問題が発生したときに、呼び出し元にメッセージとともに発生するエラー（例外）を返すことができるのですね。

例外処理を行うことにより、実行時エラーを検出した場合、異常終了せずにその出力内容を変更することができることを、サンプルコードで学ぶことができました。

＞sample1.py で、status_code で異常検出した場合と、csvを解析して所望のキーが見つからなかった場合で出力内容を変更できました。
実際に、コードを動かして検証しました。

・sample1.pyは、URLが間違っていた場合は、「サーバからの応答不正:404」という結果をコンソールに表示させて終了することができます。

raise ValueError(f'サーバからの応答不正:{response.status_code}')

「サーバからの応答不正:404」

・csvを解析して所望のキーが見つからなかった場合は、所望のキーの情報が見つからなかったことをコンソールに表示させて終了します。

raise ValueError(f'{self.type_name}の情報がみつかりませんでした')

wikipedaiの情報がみつかりませんでした

・csvを解析して所望のキーと一致した場合
try文の中で実行したコードでエラーがなく、exceptをぬけた場合は、elseで戻り値をプリントする処理ができるのですね。

if __name__ == '__main__':
    try:
        result_from_func_c = get_price_string()  # [0] 大元の呼び出し
    except ValueError as e:
        print(e)
    else:
        print(result_from_func_c)

sample2.py で、戻り値として Noneを返すことを想定し、逐一None(おかしな戻り値）が返される場合に備えた条件分岐を書くと、その条件分岐を書く手間や煩雑さに加え、情報が多くなり可読性が悪くなる・見通しずらくなること改めてコードを動かしてみて実感しました。

＞try ... except 文を使うことのメリットとして、内部で呼び出されたプログラム内の様々なタイミングで生じかねない種々のエラーを一箇所でハンドリングできるということも挙げられます。
＞以下の sample3.py では、 ValueError だけでなく、 requests.exceptions.ConnectionError もハンドリングするようにしました。
そのためにしたことは、sample1.py のプログラムで、同レベルの処理としてほんの2行を追加しただけです。
それですべてが済むのですから、簡単ですね。
端末のwifiをオフにする等、手元のマシンをインターネットから切り離しから実行してみてください。

requestsを利用する際のエラーハンドリングについてもご教示くださいまして、ありがとうございます。

・except requests.exceptions.ConnectionError as e:を書かないでインターネットから切り離す
→相手のWebサーバーに接続できないことから異常終了となり、コンソールに赤字で異常終了の結果が表示されます。また、adapters.pyというモジュールがでてきました。

・except requests.exceptions.ConnectionError as e:を書くと、異常終了せずにコンソールに以下の結果が出力されました。

HTTPSConnectionPool(host='flask.pc5bai.com', port=443): Max retries exceeded with url: /stock/info/csv/ (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x0000025FD02736D0>: Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))

これから自分も例外処理を踏まえたコードがかけるよう、勉強をすすめていきたいです。
ありがとうございます。

2022/11/23 14:27

> 例外処理を行うことにより、実行時エラーを検出した場合、異常終了せずにその出力内容を変更することができることを

ここまで実装とその機能について説明したうえで改めてシンプルに言うと、以下のとおりです。

[a] 実行時エラーにも、想定内のもの、想定外のものがある。
[b] 想定内のものは、 try ... except 節でハンドリングする。(想定外の場合は潔く強制終了を受け入れる)

ということで。
「出力内容を変更する」ことも可能ですが、そのためだけにこの構文があるわけではないということは改めてお伝えしておきます...。

たとえば、今回提示したサンプルコードでも、 requests.exceptions.ConnectionError が出た場合には「別サーバにデータを取りに行く」とか、「保存している中で最新のCSVからデータを取ってきて出力する」とか、そういう処理に進むかもしれません。


> try文の中で実行したコードでエラーがなく、exceptをぬけた場合は、elseで戻り値をプリントする処理ができるのですね。

finally というキーワードもあります。
これも含めて、次章で説明しています。

> 逐一None(おかしな戻り値）が返される場合に備えた条件分岐を書くと

例外が発生した場合のことを考慮外にすることで、これらの関数の定義もシンプルにできますね。

Excel VBAにはない概念や構文の形も含まれているので最初はとっつきにくいかと思います。
(そもそも、「クラスとインスタンス」もそうですが... (^^; )
ですが、仕様の意図を汲んで実装できるだけの力がついてきたときには、Excel VBAとはまったく違う楽しさを実感できるだろうとも思います。

ひきつづき、楽しんで学んでください v(^^*

2022/11/23 15:28

小川先生

丁寧に解説くださいまして、ありがとうございます。
これからエラーのハンドリングについても勉強して、適宜必要に応じた処理ができるようになりたいです。
ありがとうございます。

>ですが、仕様の意図を汲んで実装できるだけの力がついてきたときには、Excel VBAとはまったく違う楽しさを実感できるだろうとも思います。

楽しんで学んで、実感できるようになりたいです。

2022/11/25 19:24