gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GError (Re: [Gnu-arch-users] "librifying" libarch)


From: Colin Walters
Subject: Re: GError (Re: [Gnu-arch-users] "librifying" libarch)
Date: Mon, 20 Oct 2003 23:27:56 -0400

On Mon, 2003-10-20 at 21:51, Tom Lord wrote:

> Some languages have some kind of construct for defining an official
> "module".  C doesn't.  Even in languages that have modules, in
> informal discussion, a "component" or "layer" may be one module,
> multiple modules, or parts of multiple modules.  

No, you say "this is a module" in your software.  Period.

> The idea of
> "component" or "layer" may _change_ depending on the context of the
> discussion -- 

That means you didn't classify things well enough :)

> So, if you tell me to identify error codes with some "module" I'm not
> at all clear on why'd I want to do that or what it might mean.

For the purposes of identifying the source of the error; I gave reasons
why you want to do that in my previous mail.

>   Does
> that mean that only the code in that module (if the language has
> official modules) can generate that error?  

Of course.  

> In cases like that, B is defined has returning any of a set of
> possible values, some of which it might just be forwarding from C.
> But A shouldn't know they're coming from C.   As far as A is
> concerned, it's an error from B.

Nono; in languages like Java, every method has to declare the types of
exceptions it can throw.  And in this case, B would declare its methods
as throwing exceptions from C.  And this is quite common; a number of
packages can throw java.io.IOException.  It doesn't violate modularity,
because the fact that B is built upon C is *part of the API* of B.

> The point is this:  Am I ever _really_ going to want to write code
> like:
> 
>       if (my_gerror->domain == C_domain)
>           {
>             ....
>           }

Sure.  I personally never have :)  But you could.

> 
> Did the author of com.example.b tell you that his method might return
> a com.example.c.NetworkResetException? 

Yes.

> Yes: Well, then the author of com.example.b screwed up.  Because in
>      truth, he only wants to forward up to his callers the
>      com.example.c.* exceptions from _certain_calls_ in his code.  And
>      in forwarding them up, he really means "Uh, b returns this same
>      kind of error."  He might later add additional calls to C that
>      _shouldn't_ forward up in the same way.  So, really, b should be
>      catching the error com.example.c.NetworkResetException and
>      turning it into com.example.b.NetworkResetException. 

It's a worthless waste of time to rewrite/redeclare all the exceptions,
when you can just reuse the ones from the lower layer.

> The other thing to notice here is you didn't write:
> 
>       except (com.example.c.* e)

except (com.example.c.Exception e), but yeah.

> and that's my primary point: the `domain' foo is a wart on the GError
> interface.

No, because you have to use the domain *and* the code together actually
to differentiate between errors.  So it looks like this:

if (error && error->domain == RHYTHMDB_ERROR_TYPE 
     && error->code == RHYTHMDB_ERROR_DATABASE_CONNECTION_REFUSED)

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]