きり丸の技術日記

技術検証したり、資格等をここに残していきます。

テストのメールドメインはexamle.comのほかにもある(RFC 2606)

テスト時に使用するメールドメインについてexample.comを使用していますが、メールドメインで制御しているコードを検証したい時にほかにも安全に使えるドメインがないかを調べたときのメモ。

すでに飽和している情報ですが自分のメモのために残します。

テストで使えるトップレベルドメイン

RFC 2606

RFC 2606で定義されているものは次の4つです。

  • .test
  • .example
  • .invalid
  • .localhost

使い分けについては、RFC 2606で提案されています。

IANA(ICANN)

ICANN(国際的な非営利法人)にて管理しているトップレベルドメインがあります。

  • テスト
  • 测试
  • 測試
  • испытание
  • परीक्षा
  • δοκιμή
  • 테스트
  • பரிட்சை

等々。ほかに3つありますが、アラビア語等の右横書き言語(RTL言語)でのマークダウンの書き方が分からなかったので、知りたい方はIANAのページを調べてください。

IANAとICANNについて

IANA(Internet Assigned Numbers Authority)が管理していたものを、ICANNが管理するようになりました。現在では、IANAという名称自体は、ICANNの機能名のひとつとなっています。

テストで使えるセカンドレベルレベルドメイン

RFC 2606

RFC 2606で定義されているものは次の3つです。

  • example.com
  • example.net
  • example.org

どうしてもそれ以外が使いたい時

どうしてもそれ以外のメールドメインが使用したい場合、DNS Lookupで確認してください。応答がなければ、おそらくそのコマンドを実行している段階では存在しないDNSでしょう。

$ nslookup example.com
Server:         XXX.XXX.XXX.XXX
Address:        XXX.XXX.XXX.XXX#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34
Name:   example.com
Address: 2606:2800:220:1:248:1893:25c8:1946

$ nslookup example.com2
Server:         XXX.XXX.XXX.XXX
Address:        XXX.XXX.XXX.XXX#53

** server can't find example.com2: NXDOMAIN

備考

ドメインは右から解釈するので、トップレベルドメインさえ例示したものにすれば問題ないです。

aaa.bbb.example等々。

終わりに

難しいことは考えずにexample.comexample.netを使用すればよいです。ただ、co.jpについては国際的な予約済みドメインではないので、注意しましょう。

なお、例示可能なドメインとしてJPRSで定義しているので、example.co.jpを使用しても問題はありません。

参考情報

Pythonのエラーチェイン(例外を元に例外を投げる)には3種類あるがあまり気にしなくていい

Pythonでフレームワークから発生した例外を元に、適切に自作した例外に変換する方法に複数あることを知ったので、それを素振りしました。

なお、結果だけ先にお伝えするとraiseするだけでも9割問題ありません。

環境

  • Python
    • 3.11.6

確認方法

Pythonでは単純にエラーをraiseするだけでなく、from efrom Noneという構文を付けてraiseすることもできます。

try:
    try:
        1 / 0
    except ZeroDivisionError as e:
        raise ValueError("ERROR") # 1つ目
        raise ValueError("ERROR") from e # 2つ目
        raise ValueError("ERROR") from None # 3つ目
except Exception as e:
    print(traceback.format_exc())

具体的にtraceback.formt_exc()で得られるstacktraceは次のとおりです。

# 1つ目のraise
tests/unit/test_raise_error.py Traceback (most recent call last):
  File "/tests/unit/test_raise_error.py", line 9, in test_01
    1 / 0
    ~~^~~
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tests/unit/test_raise_error.py", line 11, in test_01
    raise ValueError("ERROR")
ValueError: ERROR
# 2つ目のraise
Traceback (most recent call last):
  File "/tests/unit/test_raise_error.py", line 9, in test_01
    1 / 0
    ~~^~~
ZeroDivisionError: division by zero

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/tests/unit/test_raise_error.py", line 11, in test_01
    raise ValueError("ERROR") from e
ValueError: ERROR
# 3つ目のraise
Traceback (most recent call last):
  File "/tests/unit/test_raise_error.py", line 11, in test_01
    raise ValueError("ERROR") from None
ValueError: ERROR

差分としては次のとおりです。

  1. 1つ目のやり方
  2. エラーメッセージにDuring handling of the above exception, another exception occurrが出力される
    1. 例外処理中に例外が発生しました
  3. 2つ目のやり方
  4. エラーメッセージにThe above exception was the direct cause of the following exceptionが出力される
    1. 上記の例外が直接の原因で次の例外が発生しました
  5. 3つ目のやり方
  6. 元の例外を握りつぶす

結論

正確に例外を表現するならraise Error from eを使用してください。

ライブラリやフレームワークを作成したり、テスト用の便利なモジュールを作っているときに、例外を伝播させたくないときにはraise Error from Noneを使用してください。

Pythonとしては、例外は意図的に握りつぶさないので単純にraiseするだけでも9割のケースで問題ないでしょう。

ソースコード

終わりに

個人的に、raise from eにはもう少し情報が増えることを期待していました。もちろん、正確に表現するならraise from eがあったほうが良いです。しかし、stacktraceを読もうとしているときは不具合の原因をいち早く確認したいので、まずは発生箇所を特定することを最優先してしまい、結果としてDuring handling of the above exception, another exception occurrというメッセージは今まで目に入ってこなかったです。

まぁ、知識として知ったうえで単純にraiseすることは今後無くなるでしょうが、かといって無理やり既存のコードにraise from eを付与するほどではないので、結論としてはあまり気にしなくていいです。

Gitにchmodした結果を含めない、そして復帰させた時の手順(core.fileMode)

WSLで開発中にroot権限で作成されたファイルがあり、IntelliJ IDEAで更新できなかったファイルがありました。そのためディレクトリごとchownchmodを行ったのですが、Gitに変更箇所があると検知されてしまい、気づかずにコミットしてしまいました。

今回の記事では、chmodを行っても検知されないようにする設定方法と誤ってコミットしてしまったときの復帰手順の操作を記載します。復帰手順に関しては、もっといいやり方がありそうですので、もし同じ事象にハマったら教えてください。

環境

  • Git
    • 2.34.1
  • IntelliJ IDEA
    • 2024.1 EAP

設定方法

次のコマンドを実行すれば、chmodしても結果がコミットされなくなります。

git config --global core.fileMode false

復帰方法

  1. 一時ブランチを切る
  2. 目的のブランチを戻したいコミットまで戻す

IntelliJ IDEAのGit(Alt + 9)で操作しました。目的のコミットを選択しながら右クリックでReset Current Branch to Hereを選択してください。次に出現するウィンドウはHARDを選択してください。

  1. 一時ブランチで目的のコミットから目的のファイルだけget From Revisionで戻す

終わりに

普段なら戻したいファイルをRevert Selected Changesで選択していましたが、chmodの変更は戻せませんでした。復帰方法をまとめてくれる記事は今までなかったと思うので、これを機に同じ失敗した人に役立てばいいと思います。

なお、Chat GPTからは目的の答えは聞き出せませんでした。

類似記事