Python Exception Handling, Return it or Raise it ?

[metalalive]

Hi , @teds-lin and @wingtkw

as the lines of code increases and the application has been getting complicated,
it is time to decide whether we should always raise exceptions or return them, or any other hybrid approach.

I am reading the articles to see whether I can come up with some good practice for this game application.

• Python's raise: Effectively Raising Exceptions in Your Code
• Do I raise or return errors in Python?

I never thought questions like this,
if you know any good-quality article or discussion threads, please post links at here,
you can also leave comments in this thread, I'll appreciate any feedback.

I would also probably ask similar questions in other online Python communities.

Thanks

[teds-lin]

我是指單一檔案內避免混用raise exceptions 與return error
例如backend/app/domain/game.py中同時使用raise exceptions 與return error

• 拋出異常(Raise Exception)需強制處理錯誤，適用於無法繼續執行的嚴重錯誤
• 返回錯誤(Return Error)提供更多彈性，適用於非關鍵錯誤

實務上可根據需要選擇合適的錯誤處理方式，例如我認為業務邏輯部份使用拋出異常,外部介面使用返回錯誤,讓系統有清晰一致的錯誤處理機制，以目前專案目錄結構為例，可能是：
app/adapter/repository/in_mem.py:

• 拋出異常(Raise Exception)
• 因為這是儲存庫的實作,使用拋出異常的方式可以更好處理與資料存取或持久化相關的錯誤,能中斷程式執行並提供詳細錯誤資訊以幫助除錯。

app/adapter/api.py:

• 自定義HTTP異常(Custom HTTP Exception)
• 這個檔案負責處理HTTP請求和回應,使用自定義HTTP異常可以更好處理與無效請求或伺服器端錯誤相關的錯誤,提供明確的錯誤狀態碼和訊息來增進錯誤處理的彈性。

app/adapter/presenter.py:

• 返回錯誤(Return Error)
• 這個檔案負責將資料呈現給使用者介面,使用返回錯誤的方式可以更好處理與資料呈現相關的錯誤,在需要時提供詳細錯誤資訊並根據需要進行錯誤處理。

app/domain/game.py 和 app/domain/player.py:

• 拋出異常(Raise Exception)
• 這些檔案代表領域實體,使用拋出異常的方式可以更好處理與領域相關的錯誤,能中斷程式執行並提供詳細錯誤資訊以幫助除錯。

app/usecase/config_game.py:

• 拋出異常(Raise Exception)
• 這個檔案包含設定遊戲的用例邏輯,使用拋出異常的方式可以更好處理與用例相關的錯誤。

app/dto.py:

• 返回錯誤(Return Error)
• 這個檔案負責驗證和處理輸入輸出資料,使用返回錯誤可以更彈性地處理驗證失敗等情況。

[metalalive]

OK , here is my thought about the issue

Raise Exception

• exception forces developers to explicitly handle the error happening at lower-level code
  • (e.g. by try...except... in Python)
• when to raise :
  • the type of error is critical to the application.
  • it is required to signal the error and let app knows it is happening and deal with it now.

Return exception

• for flexibility, a function can also simply return an exception, let the caller to raise it
• when to raise :
  • if it is more appropriate to let callers decide to raise it , then return it.
  • the error is less important to the application, and the handling process can be deferred

About this game project

For domain models , the error MAY or MAY NOT be crucial :

• Game.add_players() currently raises GameError ,
  • if number of players does not range from 2 to 4 , then we cannot play the game.
  • it is crucial to the game, it makes sense to raise it
• Game.assign_character() , currently it returns GameError
  • the error happens for invalid investigator or already selected one
  • it is debatable to say it crucial
    • for any error , you can simply discard the invalid new value.

The questions now are :

• should we expect all errors from domain models are crucial ? and have to raise them ?
• if the decision is made case by case, would it be tedious to you ?

For repositories , the error is mostly crucial :

• if a repository failed to save and fetch a game state, you cannot play the game since then
• it is good to always raise it.

For use-case layer

• when a use-case instance catches an exception, it should be the last stop which determines what to do.
• I still don't have specific opinion about how the error can be handled at this layer
  • Ted and Wing, you decide. lol

For DTO and presenters

• it is mostly about serialization and de-serialization, no application logic there
• it is OK to simply return the error

[teds-lin]

if the decision is made case by case, would it be tedious to you ?

從我前面的論述，應該看的出來是從整體架構方面去思考
外層(靠近API使用者)用Return exception，而內層用Raise Exception，這只是個人想法並非一定正確
只是希望藉由這樣統一「層」級別的錯誤處理方式，加速對程式碼理解速度與降低維護成本

如果「層」沒有統一的error handling話，像這邊我就會需要去檢查下面每個呼叫到的方法，是否都是使用Return exception，所以可以直接用is None就好，還是需要try/except去補抓raise

[metalalive]

OK, it seems that we agree on the coding style in most of the modules, which is good.

外層(靠近API使用者)用Return exception，而內層用Raise Exception，這只是個人想法並非一定正確
只是希望藉由這樣統一「層」級別的錯誤處理方式，加速對程式碼理解速度與降低維護成本

Agree, I know that it is not accurate but will save time in application development.
That is why I asked the questions in my previous comment :

• should we expect all errors from domain models are crucial ? and have to raise them ?
• if the decision is made case by case, would it be tedious to you ?

Before I saw this comment ,
I didn't really know whether you prefer to always chases correctness / accuracy ?
or you chose sub-optimal approach to make the work easier ?
(I guess that is kind of like trade-off)

OK
It is also acceptable to consider the errors from the entire domain layer should be raised / thrown to upper layer.

[metalalive]

@wingtkw , please let us know about your thought in this coding issue,
I guess we could almost conclude the discussion soon.

[metalalive]

@teds-lin , let us wait for Wing's reply by the end of the day (23:59:59, 8th. Nov. 2023) ,
If she never responds,
I will temporarily close this discussion ,
and move back to the PR28 to describe how I would modify the code,

@wingtkw , please spend few minutes describing your thought on this issue ,
in this project we wish to have consistent coding style on error-handling issues.
thanks

[wingtkw]

My opinion towards return exception or raise exception are quite similar to you two
where raise exception is for critical issue, while return exception is for less important, non-critical error that the handling can be up to client
For me, I don't mind chasing accuracy (well after all it's a project for practicing coding skills, right)
For whether or not the errors from the entire domain layer should be raised / thrown to upper layer, I don't really have a strong opinion for that, so it's up to you

[metalalive]

OK , thanks, good to know your thought on this

[metalalive]

Recap

In this game app we transfer the error in following manner :

• API endpoint : Custom HTTP Exception
• repository / gateway to database : Raise Exception
• entity / domain model : Raise Exception (for simplicity)
• use-case layer : Raise Exception
• DTO , presenter : Return Exception