You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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. ↩
The text was updated successfully, but these errors were encountered:
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:
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.
SILE.resolveFile()
warns if it does not resolve the file (and returns nil afterwards)sile/core/sile.lua
Line 397 in 770d2b9
I think this is probably bad:
SILE.resolveFile(...) or SU.error(...)
pattern or with a fullif
) -- In those case, we'll get a warning and then an error for the exact same thing.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
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. ↩
The text was updated successfully, but these errors were encountered: