Re: Header files with enums instead of defines?

From: Paul Richards (paul_at_originative.co.uk)
Date: 12/23/04

  • Next message: Paul Richards: "Re: FreeBSD's Visual Identity: Outdated?" 
    Date: Thu, 23 Dec 2004 13:26:03 +0000
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

    On Wed, Dec 22, 2004 at 06:45:16PM +0100, Poul-Henning Kamp wrote:
    > In message <20041222010143.GS53357@wantadilla.lemis.com>, "Greg 'groggy' Lehey"
    > writes:
    >
    > >Has anybody thought about replacing #defines with enums in header
    > >files? It would make debugging a whole lot easier. Foe example, I'm
    > >currently looking at a debug printout which contains:
    >
    > I agree with others who have shot this down: compatibility would
    > not allow us to do something like that.
    >
    > But that is not to say that the error reporting mechanism could not
    > be improved in other ways.
    >
    > One of my pet peeves is that comples system calls have no way to
    > convey additional information about why the return a given
    > return value like EPERM.
    >
    > I would almost advocate adding a char[X] to each thread and a
    > system call which could retrieve it. Complex system calls like
    > mount/nmount, ioctl and similar could then stick an explanation
    > into that string which strerror(3) or err(3) and similar functions
    > could pull out and give the user.
    >
    > There is a heck of a difference between getting:
    >
    > fdisk: permission denied
    >
    > And
    >
    > fdisk: permission denied (partitions overlap)

    For all projects I've worked on in recent years the first thing
    I've done is implement an error reporting stack, which basically
    works in a similar way to exceptions in C++/Java i.e., the error
    percolates up from where it occurs to a point where something decides
    to handle it. The error object itself varies from project to project
    but always includes a message. At whatever point in the stack where
    something handles the error you can then get a full report as to
    what each layer in the stack did.
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Paul Richards: "Re: FreeBSD's Visual Identity: Outdated?"