Replace to broad exceptions into the Dev

[Taragolis]

Similar to: #38344

This one less affect the tests but still better to use custom or other more appropriate builtin exceptions rather than just Exception.

This one was found by TRY002 rule it has a bit confusing message

❯ ruff check dev --select "TRY002"

dev/breeze/src/airflow_breeze/commands/release_management_commands.py:1069:19: TRY002 Create your own exception
dev/breeze/src/airflow_breeze/commands/release_management_commands.py:1094:15: TRY002 Create your own exception
dev/breeze/src/airflow_breeze/commands/release_management_commands.py:1219:19: TRY002 Create your own exception
dev/breeze/src/airflow_breeze/global_constants.py:363:15: TRY002 Create your own exception
dev/breeze/src/airflow_breeze/utils/docs_publisher.py:61:19: TRY002 Create your own exception
dev/breeze/src/airflow_breeze/utils/kubernetes_utils.py:95:11: TRY002 Create your own exception
dev/breeze/src/airflow_breeze/utils/packages.py:136:19: TRY002 Create your own exception
dev/breeze/src/airflow_breeze/utils/packages.py:180:15: TRY002 Create your own exception
Found 8 errors.

We might want to activate this rule later on, just need to resolve it into the providers first (or add noqa):

❯ ruff check airflow/providers --select "TRY002"
...
Found 59 errors.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[potiuk]

Nice

[uranusjr]

I feel some of the exceptions shouldn’t be ValueError. This type is for when a value is not right, but some of those aren’t specifically pointing to a value. RuntimeError would be better for at least some cases.

[Taragolis]

I feel some of the exceptions shouldn’t be ValueError. This type is for when a value is not right, but some of those aren’t specifically pointing to a value. RuntimeError would be better for at least some cases.

Could you point in which cases better use RuntimeError ?

[potiuk]

Answering for @uranusjr I think possibly yes - those that do not print value that is wrong, could be runtime errors. This is completely incosequential though in dev tools, because those exception are not a 'library" type of exceptions that could be handled by a caller in a different way.

But if I were to made a rule for nit-picking and wanting to be really, really, really strict here:

"if we do not print the value that is wrong and if the value is not directly provided by the user, it should be a runtime error."

But I am ok with any approach here, as it is, as I said inconsquential.

[potiuk]

BTW. If we want to be REALLY correct here - every time we send a ValueError (i.e. user provided a value that is wrong), we should do:

get_console().print("[error]The value xxxx you provided is wrong, correct value is .....")
sys.exit(1)

Generally speaking raising exception when user input and user console tools is involved, is quite wrong.. So if we want to correct it, then I'd rather say:

• RuntimeError, whenever it is an irrecoverable error that user has no influence on
• sys.exit(1) with [error] message and advice to the user in all other cases. will make some suggestions.

[potiuk]

Added my suggestions. @uranusjr -> maybe you can review those and say what you think?

[potiuk]

Should we just complete thaat one :) ?

[Taragolis]

I hope I do not miss any suggested changes

[Taragolis]

The error in the tests not related to this changes