[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
diaper pattern lurking in ui.scm
From: |
Christopher Allan Webber |
Subject: |
diaper pattern lurking in ui.scm |
Date: |
Sat, 30 May 2015 12:37:36 -0500 |
I was working on a new package and found that I was very surprised that
suddenly guix told me that "guix package" did not exist:
address@hidden:~/devel/guix$ guix package --help
guix: package: command not found
Try `guix --help' for more information.
Whaaaa?
So I dug into the source and found that in ui.scm there's this:
(define (run-guix-command command . args)
"Run COMMAND with the given ARGS. Report an error when COMMAND is not
found."
(define module
(catch 'misc-error
(lambda ()
(resolve-interface `(guix scripts ,command)))
(lambda -
(format (current-error-port)
(_ "guix: ~a: command not found~%") command)
(show-guix-usage))))
(let ((command-main (module-ref module
(symbol-append 'guix- command))))
(parameterize ((program-name command))
(apply command-main args))))
That catch of 'misc-error was the problem that was hiding the relevant
exception. I removed the "catch" and got guix to raise the real error.
I had a real, actual problem with my package... I had done this:
(source (origin
(method url-fetch)
(uri (string-append
"http://download.gna.org/guile-dbi/guile-dbi-"
version
".tar.gz"))
(sha256
(base32
"3545ec6b589eaa601eb1ed275c00be0cc9ba08204a252415b205f1befce7d64a"))))
Oops, I had just copied and pasted `sha256sum guile-dbi-2.1.5.tar.gz'
output into the sexp structure I borrowed from another package. So the
error that was *really* being thrown was:
In guix/packages.scm:
182: 4 [#<procedure 21e7600 (str)> #]
In guix/base32.scm:
260: 3 [base32-string-unfold-right #<procedure 2aaa3a0 at
guix/base32.scm:277:28 (chr)> ...]
In unknown file:
?: 2 [string-fold-right #<procedure 2a825a0 at guix/base32.scm:260:23 (chr
index)> ...]
In guix/base32.scm:
261: 1 [#<procedure 2a825a0 at guix/base32.scm:260:23 (chr index)> #\e 5]
In unknown file:
?: 0 [scm-error misc-error #f "~A ~S" ("invalid base32 character" #\e) #f]
ERROR: In procedure scm-error:
ERROR: invalid base32 character #\e
Aha, of course! That wasn't a base32 sha256 after all. No wonder!
Unfortunately, instead of getting this useful error that could have
helped me figure out my mistake above, the catch-all exception handling
hid my real problem from view.
I'm afraid we've fallen victim to the Diaper Pattern here:
http://mike.pirnat.com/2009/05/09/the-diaper-pattern-stinks/
I think that a more explicit exception should be being thrown and caught
in ui.scm. I could generate a patch, but I don't know what exception
it's expecting might be raised.
In other words, (error) considered harmful, use (throw 'specific-key)
instead :)
- Chris
- diaper pattern lurking in ui.scm,
Christopher Allan Webber <=