On Fri, Aug 12, 2022 at 12:12:13AM +0000, Adam D Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 11 August 2022 at 23:50:58 UTC, H. S. Teoh wrote:
> > I think the OP's idea is somewhat different: adding contextual
> > information to a propagating exception that the throwing code may
> > not have access to.
>
> Yeah, but you can use the mechanism again: you'd catch the one then
> throw a new one with the old one tacked on the back.
True. But having to insert try/catch syntax wrapping around every
potential abstraction level that might want to add contextual
information is a pain. If we could use a wrapper that can be inserted
at strategic entry points, that'd be much better.
> > The OP's idea of wrapping throwing code with a function that tacks
> > on extra information is a good idea.
>
> Yeah, that is good. I also kinda wish that scope(failure) could do it
> so you could tack on info with a more convenient syntax... i have some
> more wild ideas brewing now lol
Hmm! That gets me thinking. Maybe something like this?
// Totally fantastical, hypothetical syntax :P
auto myFunc(Args...)(Args args) {
int additionalInfo = 123;
scope(failure, additionalInfo);
return runUnreliableOperation(args);
}
T
--
"No, John. I want formats that are actually useful, rather than over-featured
megaliths that address all questions by piling on ridiculous internal links in
forms which are hideously over-complex." -- Simon St. Laurent on xml-dev
