search

jimporter / bfg9000

bfg9000 - build file generator
https://jimporter.github.io/bfg9000
BSD 3-Clause "New" or "Revised" License
76 stars 21 forks source link

Error reporting hides exception type #132

Closed abingham closed 4 years ago

abingham commented 4 years ago

It seems that bfg's error reporting for exceptions hides the exception type. For example, here's a portion of an error report it produces:

$ 9k build
error: build.bfg:107: 
  . . .
  File "build.bfg", line 107, in _render_slide_remote
    files=find_files(str(slide_dir), filter=exclude_pycache),

What's going on is that exclude_pycache (used in the filter) is calling str() on a bfg9000.platforms.posix.PosixPath. This results in a NotImplementedError (which in itself is strange) that has no message. It appears that the log formatting applied to the StackfulStreamHandler is actively discarding exception information, so by the time it produces logging output it can't tell me anything about what went wrong in this case.

In cases like this, where I'm still finding my way through bfg and doing "incorrect" things like stringifying paths, it would be very helpful to get a better indication of what went wrong.

jimporter commented 4 years ago

This is 50% intentional and 50% accidental. Most of the time, errors reported by the logging system should be "friendly" and contain an explanation of what happened, so the type is just noise. However, sometimes an "internal" error bubbles up and now it's all confusing. I should probably fix this by tagging all the "friendly" errors with a particular base type so bfg knows that they don't need their type logged. In the short term, you can add --debug to get the full stack trace, which should indicate the type wherever the exception is raised...

As for why you're getting that error, Path objects are a "safe string" type, and those are forbidden from being turned into regular strings via str. This is to ensure that the build backends are able to properly add escape sequences so that everything works right. The solution here is to remove the str() call, since find_files() should be able to accept a Path object (if not, there's a bug).

jimporter commented 4 years ago

I should probably fix this by tagging all the "friendly" errors with a particular base type so bfg knows that they don't need their type logged.

This ended up not working out very well, since some built-in Python exception types (e.g. TypeError) should sometimes be friendly errors and sometimes not. So now the NotImplementedError has a nice message, and passing --debug adds the exception type to the terminal output.