Cannot control/except processing tag error in latest version

[joon612]

Describe the bug
When I was working with a large number of dcm files, some of the elements in the dcm didn't conform to the specification (which was out of my control), and then when my script ran, it would generate a lot of error logs.

Expected behavior
I feel like I should be able to catch exceptions or control logs.

Steps To Reproduce

    metadata_dict = {}
    try:
        metadata_dict.update(dcm.file_meta.to_json_dict(suppress_invalid_tags=True))
        metadata_dict.update(dcm.to_json_dict(suppress_invalid_tags=True))
    except ValueError as e:
        logging.error(f"Error occurred at tag: {e.args[0]} file: {metadata_file}")
    except Exception as e:
        logging.error(f"{e}: {metadata_file}")

Your environment

$  python3.9 -m pydicom.env_info
module       | version
------       | -------
platform     | Linux-5.15.0-1049-azure-x86_64-with-glibc2.31
Python       | 3.9.18 (main, Aug 25 2023, 13:20:04)  [GCC 9.4.0]
pydicom      | 2.4.2
gdcm         | _module not found_
jpeg_ls      | _module not found_
numpy        | 1.26.0
PIL          | 10.1.0
pylibjpeg    | 1.4.0
openjpeg     | _module not found_
libjpeg      | 1.3.4

[mrbean-bremen]

You already suppress exceptions by setting suppress_invalid_tags=True, and the invalid tags are just ignored.
What you can't suppress currently is the error logging - I guess the issue is about that?

[joon612]

You already suppress exceptions by setting suppress_invalid_tags=True, and the invalid tags are just ignored. What you can't suppress currently is the error logging - I guess the issue is about that?

Indeed.

[mrbean-bremen]

What I would have expected in this case (e.g. if suppress_invalid_tags=True) would be a warning, not an error.
But I guess you want to have that logging configured away completely, right?

[joon612]

What I would have expected in this case (e.g. if suppress_invalid_tags=True) would be a warning, not an error. But I guess you want to have that logging configured away completely, right?

In fact, there are two parts, one is that the error is too concise, I actually do not know the specific reason for the element is not compliant, the other is that I can't control the log, in the past, this kind of is used as a warning, although I can't control them at that time, second, I actually care more about whether it is exported, if it can be exported or processed, it can not be displayed as a warning, if it (element) can not be exported, export the reason.

[mrbean-bremen]

I actually care more about whether it is exported, if it can be exported or processed, it can not be displayed as a warning, if it (element) can not be exported, export the reason.

I guess by "export the reason" you mean log it?
Currently, the error means that an exception has happened during processing, so the tag will not be exported. It makes indeed sense to at least log the original exception in this case instead of the generic one.

[joon612]

I guess by "export the reason" you mean log it?
Yes and thanks!