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
An internal SCons routine, SCons.Errors.convert_to_BuildError, attempts to synthesize a BuildError exception from whatever exception may have been raised when the Taskmaster executes an action. This can go wrong in certain circumstances. The docstring for the BuildError class contains these comments:
errstr: a description of the error message status: the return code of the action that caused the build error. Must be set to a non-zero value even if the build error is not due to an action returning a non-zero returned code.
In the case reported in the linked thread, the Jinja templating engine (used in-process) raised a jinja2.exceptions.TemplateNotFound exception, which is initialized in a kind of odd way (separate topic), where the three important exception fields filename, strerror and errno are all set to None. The conversion routine then tries this (status contains the captured exception at this point):
before stuffing those values into the BuildError instance. As written, strerror and errno will remain None if they were None in the original exception, which is not the intent of the routine, as described in the docstring (the getattr defaults only apply if the attributes are not present). The effect is that the exception appears to be "swallowed". SCons should be more tolerant of this, and get the defaults in if the fields were None.
importjinja2defsmall_builder(target, source, env):
raisejinja2.exceptions.TemplateNotFound("You should see this message")
env=Environment()
env.Command(['dummy/TEST.COMPLETE'], [], small_builder, chdir=0)
The text was updated successfully, but these errors were encountered:
In some cases, the conversion of another exception to a BuildError
could yield undesired results: if the exception was a OSError/IOError,
and some fields were initially set to None, then the return code and error
string were set to None, rather than the SCons defaults (which are
return code 2, and the string set originally in the exception).
A unit test is added which attempts to build an OSError in the way
that the case "in the wild" does - confirmed failing to pick up
defaults without the change.
FixesSCons#4530
Signed-off-by: Mats Wichmann <[email protected]>
An internal SCons routine,
SCons.Errors.convert_to_BuildError
, attempts to synthesize aBuildError
exception from whatever exception may have been raised when the Taskmaster executes an action. This can go wrong in certain circumstances. The docstring for theBuildError
class contains these comments:In the case reported in the linked thread, the Jinja templating engine (used in-process) raised a
jinja2.exceptions.TemplateNotFound
exception, which is initialized in a kind of odd way (separate topic), where the three important exception fieldsfilename
,strerror
anderrno
are all set toNone
. The conversion routine then tries this (status
contains the captured exception at this point):before stuffing those values into the
BuildError
instance. As written,strerror
anderrno
will remainNone
if they wereNone
in the original exception, which is not the intent of the routine, as described in the docstring (the getattr defaults only apply if the attributes are not present). The effect is that the exception appears to be "swallowed". SCons should be more tolerant of this, and get the defaults in if the fields wereNone
.Simple repro:
The text was updated successfully, but these errors were encountered: