buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <>
Subject Re: Better error messages and Growl notifications
Date Mon, 28 Jul 2008 16:09:47 GMT
On Mon, Jul 28, 2008 at 4:41 AM, lacton <> wrote:
> On Fri, Jul 25, 2008 at 2:02 AM, Assaf Arkin <> wrote:
>> I want to know if they make your life better, just plan annoying, and
>> any ideas for making them even better.
>> ==  Stack trace
> [...]
>> I'm toying around with making this a bit better, the latest change
>> will show any number of lines (usually just one) from the buildfile.
>> If you want to help find the right balance between two much
>> information and not enough, have a look at the
>> standard_exception_handling method in lib/buildr/core/application.rb
> +1 for me.
> Showing all concerned buildfile's lines even when not running with
> --trace saves time without crowding the screen too much. Most of the
> time, there is only one line to display anyway, but when there is two
> lines to show, I find it's usually a precious piece of information.
>> == Colors for errors
>> I think it's a good idea to use a splash of color for salient
>> information.  So I started by making error messages show up in red,
>> that way they're noticeable when you run Buildr from the console
>> (warnings are now blue).  Any ideas on how to use colors more
>> effectively?
> I like your use of color. Could you give me an example of a blue message?

Right now we use warnings in three places.  Deprecated warnings, for
every deprecated method or feature.  In a few places, where we're not
sure it's an error but worth paying attention.  For example, if you
run buildr package in a directory not associated with any project, it
warns you that "No projects defined for directory ...", but it still
runs that task -- it might do some other interesting things.

The third place, a warning lists all the failed test cases for a
project.  Typically, you'll also get an error message, unless you're
running with test=all, in which case it will keep running test cases
for other projects, so you can pick up these warnings from the
console.  Although, maybe these should show as errors instead of

> What would you think of making these facilities available to buildr
> users? As a user, I would like to be able to log messages in a way
> that is consistent with buildr. I imagine four methods:
> trace "a message that will be displayed only if --trace option enabled"
> info "a message that will be displayed every time"
> warn "a message that will be displayed every time, in blue"
> error "a message that will be displayed every time, in red"

I like that.

> Or maybe the last one should be merged with the 'fail' method.

I think there's a reason to have both error and fail.  Specifically,
the test=all option allows you to run all the test cases, ignoring
errors, so there's no failure, but you'll still want to see these
error messages.


> Lacton

View raw message