Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SILE.resolveFile() warning is a tad annoying and redundant #1875

Closed
Omikhleia opened this issue Sep 15, 2023 · 2 comments · Fixed by #1888
Closed

SILE.resolveFile() warning is a tad annoying and redundant #1875

Omikhleia opened this issue Sep 15, 2023 · 2 comments · Fixed by #1888
Assignees
Labels
bug Software bug issue
Milestone

Comments

@Omikhleia
Copy link
Member

SILE.resolveFile() warns if it does not resolve the file (and returns nil afterwards)

SU.warn(("Unable to find file '%s': %s"):format(filename, err))

I think this is probably bad:

  • Most of the time, packages or classes defends themselves afterwards with a clear error (either with a SILE.resolveFile(...) or SU.error(...) pattern or with a full if) -- In those case, we'll get a warning and then an error for the exact same thing.
  • When they don't have such protection, they'll likely fail later with an even more than obscure error... It has some code smell, and the user still gets a warning and an error for the same root cause.

In terms of API, it would seem cleaner to me if it just returned nil without issuing that warning, and we properly ensured an appropriate error handling where it is invoked.

Some packages may even want to use some fallback when a file cannot be resolved, so the warning is very intrusive in that case.1

Footnotes

  1. This is how I discovered the "problem": I wanted to check if a book had some resource (as an override) with the exact same resolution logic as when files or images are included, or to use a default (module-provided) resource when it's not the case.

@alerque
Copy link
Member

alerque commented Sep 18, 2023

I agree this should be fixed. It also stinks that Lua doesn't have better error handling/raising mechanisms and we have to invent our own.

We should probably just drop the warning, but a proper idiomatic Lua way to do this would be to return two values, a status code and a result (much like how pcall() and others handle this). If the status code is falsey then the return value is an error that can be exposed or ignored at will; it truthy then the result is the actual result. I want to think about whether we should actually do that here... The downside of course is doing this the "right" way would be a breaking change.

In the mean time a short term hack would be to suppress the warning:

-- Option 1
local origwarn = SU.warn
SU.warn = function () end
local result = SILE.resolveFile("...")
SU.warn = origwarn

-- Option 2
SILE.quiet = true
local result = SILE.resolveFile("...")
SILE.quiet = false

@alerque alerque added the bug Software bug issue label Sep 18, 2023
@alerque alerque added this to the v0.14.12 milestone Sep 18, 2023
@alerque
Copy link
Member

alerque commented Oct 11, 2023

Most of our current top level APIs and functions don't have any "better" error handling either. At least for new we'll just silence this nonsense and think about error handling more carefully for future versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Software bug issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants