search

delph-in / pydelphin

Python libraries for DELPH-IN
https://pydelphin.readthedocs.io/
MIT License
79 stars 27 forks source link

Orthogonal error message on missing grammar #337

Closed dantiston closed 2 years ago

dantiston commented 2 years ago

Using ace.parse from delphin.ace with the incorrect grammar path results in the following stacktrace:

>>> from delphin import ace
>>> ace.parse('~/nope.dat', 'Hello World!')
/Users/Dantiston/nope.dat: No such file or directory
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/Dantiston/.pyenv/versions/3.8.9/lib/python3.8/site-packages/delphin/ace.py", line 495, in parse
    return next(parse_from_iterable(grm, [datum], **kwargs))
  File "/Users/Dantiston/.pyenv/versions/3.8.9/lib/python3.8/site-packages/delphin/ace.py", line 474, in parse_from_iterable
    with ACEParser(grm, **kwargs) as parser:
  File "/Users/Dantiston/.pyenv/versions/3.8.9/lib/python3.8/site-packages/delphin/ace.py", line 110, in __init__
    self._open()
  File "/Users/Dantiston/.pyenv/versions/3.8.9/lib/python3.8/site-packages/delphin/ace.py", line 143, in _open
    raise ACEProcessError("ACE process closed on startup")
delphin.ace.ACEProcessError: ACE process closed on startup

... which is super unfriendly -_- Can it be improved to be more specific?

EDIT: updated with better stack trace

goodmami commented 2 years ago

Yes, stack traces are ugly, but you've cut off the actual error message from ACE:

>>> ace.parse('~/grammars/foo/erg.dat', 'Dogs bark')
/home/goodmami/grammars/foo/erg.dat: No such file or directory
Traceback (most recent call last):
  ...

Sometimes I avoid LBYL-style constructs because they can hide the precise location or nature of an error, but if the error message from ACE is not prominent enough, I could check for the existence of the grammar file before opening the ACE process.

dantiston commented 2 years ago

@goodmami thanks, I see this was totally my fault :-) I'm running it in a unit test (hence the formatting changes) and I've been foiled by unit test placing the actual error above the summary. Thanks for dealing with my inability to do basic things!

goodmami commented 2 years ago

Ah that makes sense. Yes, sometimes when I turn off stdout capture with pytest (-s / --capture=no) I see that I'd accidentally left some debugging print statements in the code :roll_eyes: