Re: error numbers.... a continuing pain

[Alain Magloire]

> 
> Bon soir,
> 
> It's getting to the point that EINVAL is returned for  pretty
> much everything, making gdb pretty much the only way to determine
> what isn't working. sieve is having a hard time giving a useful
> diagnostic to the user.
> 
> What about assigning our own error numbers with values:
> 
> #define MU_ERR_BASE  0x10000
> 
> #define MU_ERR_MAILBOX_NULL  0x10001
> #define MU_ERR_FOLDER_NULL   0x10002
>             _MAILBOX_NOT_OPEN
>               _AUTH_FAILED
>               _BAD_FORMAT        (for url and address parsing)
> etc...
> 
> Hasn't this been kicked around before?

Yes.

> We could even break it into classes
> 
> 0x100??  generic (we've already got EINVAL, ENOMEM, etc for lots of
>                    the generic errors, but there might be others)
> 0x101??  mailbox
> 0x102??  folder
> 0x103??  mailer
> 
> What do you all think?


One of the problem, is that some apps even in our own code do things
like:
  status = mailbox_open (..);
  printf ("Error: %s\n", strerror(status));

In this case, we should provide a mu_strerror(); or mu_strerror_r();
This was introduced in mailbox2/, but nice to have in mailbox/

> Sam
> 
> p.s. Almost all the conversation about sieve on the CMU mailing
> list is of the "it's not working, and there's no indication why,
> what do I do?". I'd like to do better.

I agree, one of the nice thing about IMAP is its verbosity.