Thanks everyone for joining the discussion! I think we have some consensus. These should at least apply to new code.
1. Don’t use AirflowException 2. Use Python native whenever possible 3. Create customized exceptions instead of AirflowException But we’re worried about how and whether we should remove AirflowException. What I am thinking is removing `raise AirflowException`. As for AirflowException itself, it looks somewhat challenging. What if we do something like `CustomException(AirflowException)`, so `except AirflowException` blocks still work, but we can gain the benefit of making it descriptive. Best, Wei > On Aug 30, 2025, at 11:08 PM, Jarek Potiuk <ja...@potiuk.com> wrote: > >> I would say we should only worry about backcompat when there's something > to > worry about. > > I think Daniel is quite right. In this case what **would** happen if > someone relies on `try AirflowException`, the issue would be immediate to > see and easy to fix (and we can describe it in release notes as significant > news. I can't easily think of a "reasonable" case where behaviour would be > changed without crashing. I think that would be a blocker if we can have a > reasonable way of using it that might change the behaviour in a way that is > difficult to notice by the user, but when I think of potential cases I > cannot imagine usage that could lead to it. > > J > > > On Wed, Aug 27, 2025 at 3:31 PM Daniel Standish > <daniel.stand...@astronomer.io.invalid> wrote: > >> Generally agree with this. >> >> I would say we should only worry about backcompat when there's something to >> worry about. >> >> Like, if there's just a remote possibility that a user is doing something >> weird (e.g. in some subclass they wrote of something) then, not really for >> us to worry about. Seems rather internal behavior generally. >> >> If we *know* for sure changing it will break airflow for certain >> combinations that should work, that's something to address. >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
