Closed #495.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/495#event-1800050573___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Exceptions preserve existing interfaces, are mostly not too invasive, and a try
... catch paradigm is widely used and "intuitive" (for some nerdy definition of
the word).
otherwise sure, add additional arguments and error indicators to test while
unraveling the call stack on the error path if y
C++ doesn't seem like much of an option when you're stuck with C, but the
thought of using setjmp/longjmp makes C++ seem almost attractive ;)
I'm more tempted by some sort of callback mechanism, and perhaps ability to
register extensions to macro.c to allow at least some of the spec %foo
direct
The other impetus for adding exceptions is so the caller can provide a context
(including files and linenos when appropriate) for a failed expansion. Adding a
try...catch wrapper in the rpmbuild parser permits the parser to supply
detailed error information without changing the existing API rath
Delivering an error with rpm --expand '%ifarch' is one usage case for
exceptions that you are surely familiar with since you reported the issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softwa
I wonder what this RFE is about. I mean what's the use-case for those
exceptions?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/495#issuecomment-412346486__
RPM macro expansion (and queries and rpmlog, but those aren't this RFE) would
benefit from being able to deliver errors to callers out-of-band through an
exception, rather than in-band by writing error messages into the returned
buffer or relying on stdout/stderr.
There are 2 approaches:
* in
