#Fields
coarse trout
In Go, public struct fields are automatically functions without arguments. You need to use // +private to disable that: https://docs.dagger.io/developer-guide/go/892021/visibility
hazy frigate
But that's not what I want. That will render that field inaccessible from a downstream module right?
coarse trout
From codegen, the above shoud give you a dag.Person().Name(ctx)
I mentioned +private just to explain how the behavior is triggered.
hazy frigate
Yes I understand that and can live with that. however, the return is also a (string, error) which kind of doesn't make sense to me. Why an error?
Dagger seems to be dropping the error on actual functions where I define return with (obj, error)
coarse trout
There's a difference between module code, which is "server" side code; and codegen, which produces a "client" that calls the server code.
In the client, Dagger Functions that return a scalar (like string) are executed, i.e., there's no more chaining that can be done. So that forces a request to the API (unlazying), and that's why ctx and error is necessary. It's from the API request.
hazy frigate
ah! ok makes sense, but also very confusing. I think this is something that should be clearly explained in the docs
hazy frigate
On top of that, I think there also needs to be a section on handling and propagating errors.
coarse trout
How so?
hazy frigate
Let's say my module A has a function that returns (*Container, error). From what I understand, that error will not be thrown until a downstream module B calls a method that evaluates the DAG.
But from a user standpoint, if a different developer is working on module B they may want to tackle that error differently, but in this case that's not possible. That is an important distinction to point out in the docs because for languages like Go, it's natural to bubble up the errors so the consumer handles them.
coarse trout
It works the same way in Dagger as before. You can also get an error from any number of lazy methods, and they're only going to be returned when making the request, i.e., on leaf values of the DAG.
If you look at any pipeline, core can raise an error in any number of those. Let's say:
dag.Container().From("wat").WithExec([]string{"echo", "hello"}).Stdout(ctx)
Core will return an error on From here, due to invalid image ref, but it'll only be "caught" on Stdout, since that's when the request is made and the pipeline actually runs.
We still need to document the lazy dag model better (https://github.com/dagger/dagger/issues/3617). This is part of that.
When using a module's function in another module, you're not calling that code directly. The downstream module has a binding in the client to call... as a client. The server implementation could be in another language even. Dagger Functions just produce GraphQL fields with a matching resolver (server). But what a function does inside, can also be an API client, when accessing dag..
hazy frigate
Thanks for the explanation Helder, it makes sense. It's very important to put this explanation on paper (docs). I don't think I'm alone in being confused about the lazy vs non-lazy execution and error handling.
coarse trout
Indeed you aren't 🙂