Hi all, I would like to propose avoiding, or at least reducing, the direct use of `AirflowException`.
`AirflowException` is used extensively across our codebase, with the following occurrences: - 54 in `airflow-core` - 1,515 in `providers` - 20 in `task-sdk` `AirflowException` itself does not provide much more information than a standard `Exception`, aside from indicating that it originates from Airflow. I would like to propose the following practices, combining ideas from our previous discussion on Slack: 1. In most cases, we should prioritize using Python’s standard exceptions (e.g., `ValueError`, `TypeError`, `OSError`) instead of wrapping everything in `AirflowException`. 2. In `airflow-core`, we should define and use more specific subclasses under `airflow.exceptions`. 3. For the providers, we should also define exceptions within `airflow.providers.<provider>.exceptions`. If this approach makes sense, there are some following questions. - Should we remove the existing ones? (We previously had concerns about backward compatibility.) Or should we only apply this pattern to new pull requests? - Should we enforce it through development tools? - Is there an acceptable exception for using `AirflowException`? Best regards, Wei Lee
