Um, I dont have much experience. It depends on personal environment.
For instance, during my time at a previous company, I was required to use the company’s custom exception classes. In connection with the topic you have raised, I would like to share some of the review feedback I received in that context. https://github.com/apache/airflow/pull/53958#discussion_r2244996092 2025년 8월 27일 (수) 오후 5:16, Wei Lee <weilee...@gmail.com>님이 작성: > 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 >
