dabla commented on code in PR #38707:
URL: https://github.com/apache/airflow/pull/38707#discussion_r1561754471
##########
airflow/providers/common/sql/hooks/sql.py:
##########
@@ -111,6 +112,15 @@ def fetch_one_handler(cursor) -> list[tuple] | None:
return None
+@contextmanager
+def suppress_and_warn(*exceptions: type[BaseException]):
+ """Context manager that suppresses the given exceptions and logs a warning
message."""
+ try:
+ yield
+ except exceptions as e:
+ warnings.warn(f"Exception suppressed: {e}\n{traceback.format_exc()}",
category=UserWarning)
+
+
Review Comment:
The more I discover the code the more I think: "hey I saw this before, it
would be nice to have that as a common util code". Ofc there is the dependency
issue, it's always a trade-off at some point, unless we could like include code
dynamically like @potiuk said, but dunno if that's possible in Python. In Java
you could achieve a bit the same with an aspectj compiler at build phase. Just
wondering, if that new common util package would have no airflow dependencies,
would it then still be an issue of dependency hell, as the origin of the
dependency issues are due to the different airflow versions no? But if the new
package doens't depend on airflow (dunno if possible would have to try it),
then new providers would only have an extra dependency on that package. Or wy
try a PR as draft and see what comes out of it dunno what you guys think, at
some moment we'll have to think for a descent solution anyway.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
