Hello, Ricardo Wurmus skribis: > Mark H Weaver writes: > >> Ricardo Wurmus writes: >> >>> Mark H Weaver writes: >>> >>>> In summary, although the new messages don't look as nice in common >>>> cases, I think it's more important to ensure that we have the >>>> information we need to debug the occasional non-obvious problem. So, I >>>> think we should leave it alone :) >>> >>> I think we should strive to make the common case look good. Can we >>> achieve this without making the exceptional case harder to debug? Can >>> we caught the exception triggered by standard build phase invocations of >>> “make” but not those of custom “invoke” expressions in custom build >>> phases where the error message could be useful? >> >> I appreciate your perspective on this, and you've made some good points. >> >> How about this idea: in core-updates-next, we could add code to >> 'gnu-build' in (guix build gnu-build-system) which catches &invoke-error >> exceptions thrown by the phase procedures. This is a very common case, >> and I agree with you that a backtrace is rarely (if ever) useful for >> that particular exception type. The program name and arguments included >> in the condition object should be enough information. We could use a >> copy of the code from (guix ui) to print the invoke errors nicely: >> >> ((invoke-error? c) >> (leave (G_ "program exited\ >> ~@[ with non-zero exit status ~a~]\ >> ~@[ terminated by signal ~a~]\ >> ~@[ stopped by signal ~a~]: ~s~%") >> (invoke-error-exit-status c) >> (invoke-error-term-signal c) >> (invoke-error-stop-signal c) >> (cons (invoke-error-program c) >> (invoke-error-arguments c)))) > > This sounds good to me. > >> However, I would prefer to catch *only* invoke errors, and to let most >> exception types go unhandled by gnu-build. If you can think of another >> exception type that should be handled more gracefully, please let me >> know. > […] >> On second thought, I don't have a good justification for this. What I >> really care about is that all exceptions except for specific case(s) >> like invoke-error should generate a full backtrace to the original >> source of the exception, along with all information present in the >> condition object or exception. I see no reason not to let Guile's >> generic exception reporting code handle these unusual cases, but if it's >> important to you we could do the same thing from gnu-build, I suppose. > > I agree. I only really care about the invoke errors, because they are > to be expected when there is anything at all wrong with the build. > > Any exception other than those triggered by “invoke” could be reported > by Guile directly without us catching and reformatting them in > gnu-build. I agree, we should do this in ‘core-updates-next’. Ludo’.