read_raw_cnt() only raises one type of error

[withmywoessner]

Description of the problem

Hello! I have been working with Neuroscan CNT files through MNE again recently and I noticed that some of the exceptions raised were changed in #12792. Here is how it is currently implemented:

  input_fname = path.abspath(input_fname)
        try:
            info, cnt_info = _get_cnt_info(
                input_fname, eog, ecg, emg, misc, data_format, _date_format, header
            )
        except Exception:
            raise RuntimeError(
                "Could not read header from *.cnt file. mne.io.read_raw_cnt "
                "supports Neuroscan CNT files only. If this file is an ANT Neuro CNT, "
                "please use mne.io.read_raw_ant instead."
            )

I was wondering if I could change it to something more robust; that way I can get more specific information if the file I am trying to read doesn't exist or something similar.

Steps to reproduce

mne.io.read_raw_cnt('test.cnt', preload=True, verbose=True) (Use random nonexistent file name)

Link to data

No response

Expected results

No such file or directory: 'test.cnt'

Actual results

RuntimeError: Could not read header from *.cnt file. mne.io.read_raw_cnt supports Neuroscan CNT files only. If this file is an ANT Neuro CNT, please use mne.io.read_raw_ant instead.

Additional information

(I am not sure why it says I am in 1.6.0.dev202+g9b57c5168 instead of 1.8. I can see the latest changes.)

(PySide6=6.7.3)
├☑ ipympl 0.9.4
├☑ pyqtgraph 0.13.7
├☑ mne-qt-browser 0.6.3
├☑ ipywidgets 8.1.5
├☑ trame_client 3.5.0
├☑ trame_server 3.2.3
├☑ trame_vtk 2.8.12
└☑ trame_vuetify 2.7.2

Ecosystem (optional)
├☑ mne-bids 0.15.0
├☑ mne-connectivity 0.5.0
├☑ neo 0.13.4
├☑ eeglabio 0.0.3
├☑ edfio 0.4.5
├☑ mffpy 0.10.0
├☑ pybv 0.7.6
└☐ unavailable mne-nirs, mne-features, mne-icalabel, mne-bids-pipeline

To update to the latest supported release version to get bugfixes and improvements, visit https://mne.tools/stable/install/updating.html

[larsoner]

Agreed we should add a got:\n{_explain_exception(...)} or similiar to actually give the underlying exception as well. We have a helper _explain_exception in mne.utils that I think should format the exception nicely. Feel free to add it to #13007 if you want!