> What is the benefit of this approach over narrower exception classes? >
Let me answer it here and provide more data: * Original discussion here: https://lists.apache.org/thread/k3dxc6lmrwvqgmvjr9x53poswwpoo5o8 (It started when we had Airflow 3 development in full swing and deferred it to "after" - I guess this is the "after" :) * Original issue describing it - with some discussion https://github.com/apache/airflow/issues/43171 Quoting from that issue: Goals for this issue are the following: - Identify and revise error messages that are vague, lack context, or do not provide clear guidance on resolving issues. - Provide detailed information, context, and actionable steps within the error messages to help users troubleshoot. - Transform error messages with meaningful linking wherever possible. e.g. an error like Celery command failed on host can be transformed or displayed with something like "Please check your DAG processor timeout variable for this". So the user has a starting point to start debugging. I will let Omar go into more detail, but I think the result of those discussions was that more precise exceptions with actionable descriptions can be achieved through more "fine-grained" exceptions, This is at least my own recollection of the discussion and its current state. Or maybe that alone will be enough, Philippe, to answer the question. The discussion happened a long time ago during the Airflow 3 frenzy, so it's no wonder we all don't remember it. Luckily, our archives remember everything - this is the great benefit of "if it did not happen on devlist, it did not happen". J.
