kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

In this case (user errors/oversight) it really makes no sense to give
information which might only be helpful to developers.  I think any
organized way of dealing with messages for users (or even messages
for developers) would be greatly appreciated. As things are I'm sure
I'm not helping either - I dislike my own debug messages. :)

- Cirilo

On Fri, Dec 23, 2016 at 12:30 PM, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
> There's another little project I'd like to work on in the month or so I
> have off now:
>
> https://misc.c4757p.com/outline-error.png
>
> We have way too many error messages like that. That is, in my opinion,
> completely unacceptable. It's confusing and intimidating to anyone
> unfamiliar with kicad's... unique style of error reporting.
>
> 1. We should NOT say things like "from specctra_export.cpp :
> fillBOUNDARY() line:1165". Who needs that? Users certainly do not.
> Developers can attach a debugger and backtrace to see where the message
> is from. Developers reading bug reports can grep the source for the
> error text.
>
> 2. Similarly, we should NOT say things like "IO_ERROR". First of all
> it's wrong, that is not an IO error, we need more exception classes.
> Second of all what sort of user cares which internal exception class
> triggered an error message??
>
> 3. Broken English. "Therefore use the board boundary box."? Come on.
>
> Is anybody going to protest removing the silly dev information from the
> error messages?
>
> --
> Chris
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp