I have this:
var wd, _ = os.Getwd()
var advanceAgreementTemplateBytes, _ = ioutil.ReadFile(path.Join(wd, "/docs/templates/advance-agreement.template"))
var advanceAgreementTemplate = string(advanceAgreementTemplateBytes)
var t, _ = template.New("advance-agreement").Parse(string(advanceAgreementTemplate))
func sendAdvanceEmail(user *common.User, amount *apd.Decimal, fee *apd.Decimal, created time.Time) {
// use variables `t`, `advanceAgreementTemplate` etc here
}
I want to be able to handle the errors in the cached variables instead of using _ instead of err. Is the only way to do this is to use func init()?
If you want to error-check these, use func init or just initialize them in main.
Not all calls have Must variants, and such variants don't make sense for all calls. Don't forget that the Go way is to do proper error checking. Having Must wrappers for all possible failing calls would encourage a bad programming style, where instead of handling and propagating errors, every error would crash by default.
It's very easy to write your own Must wrappers if all you need is to crash the program on error.
The benefit of writing your own Must wrapper is that you could provide a much better error message - another thing Go encourages. ioutil.ReadFile will just say "open /docs/templates/advance-agreement.template: No such file or directory".
Related
In my code there are various types of functions with a lot of user defined parameters and return types. Most of them run in parallel as go routines. In order to be able to efficiently debug them, I want to add labels.
I went through this link on using profile labels, find go routines during debugging.
However, if I do it the way they've mentioned, ie. call the desired function inside pprof.Do, then this would mean that I would have to add this redundant piece of code everywhere.
Old code:
go executeMeAsGoRoutine(arg1 sometype, arg2 sometype)
New Code based on the links above:
go func(args1 type1, args2 type2, args3 type3, args4, type4) {
labels := pprof.Labels("some label", "some more label", "args1",strconv.Itoa(int(100)))
pprof.Do(context.Background(), labels, func(_ context.Context) {
//function that was to be called.
executeMeAsGoRoutine(arg1, arg2, arg3, arg4)// Use args1 or args2
})
}(page, i)
However most of my functions have different arguments and custom return types. If I were to enhance each go routine I will have to repeat the above code everywhere. Wherever, I am calling go runThisFunctionInGoRoutine(), I'll also have to add outer anonymous go routine, followed by pprof.Labels, followed by pprof.Do everywhere. This will lead to a lot of unnecessary code repetiton. There are already so many places where there are different go routines created.
I was hoping if I could make a generic function that would WRAP the go routine creation call as well as label creation and then does pprof.Do for me.
Can someone suggest how to do that? The source of problem is that the functions that should run as go routines are different and have different arguments.
I envision some api like:
makeGoRoutineWithLabel(labels string, functionToRun, argumentsToSupply).
NOTE: functionToRun is different each time with argumentsToSupply being different as well.
Can anyone suggest how to do this without repeating the code? A generic go routine creation wrapper which also provides a provision to add labels along.
Instead of go createGoRoutine, its something like createAGoRoutineWithLabels.
I want to run some Lambda alias specific code before my main function starts executing. It currently looks like this
func init() {
// Trying to get Lambda function alias here
}
func main() {
adapter = chiproxy.New(r)
lambda.start(lambdaHandler)
}
func lambdaHandler(ctx context.Context, req events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
c, err := adapter.ProxyWithContext(ctx, req)
return c, err
}
req in lambdaHandler has the info I need but I don't know how to get it in init()?
I don't think you can get the alias before the function has been passed a request. lambda automatically provides a number of environment variables but alias is not one of them.
That's probably because the alias is just a pointer to the version; you could have many aliases pointing to the same version, but the same function runtime could be initialized for all of them. So it wouldn't make sense to provide any particular alias at initialization time.
I want to run some Lambda alias specific code before my main function starts executing
But the function's runtime isn't specific to an alias, it's specific to a version. In fact you could create a new alias after the version had been instantiated, and the same cached runtime could be used.
I think I can see why you might want to have invokers call the same function with different aliases, but I'm not sure it's going to be a low friction path to achieve what you want with aliases. Consider whether you might instead want to create bunch of different functions - which could have the same codebase, and have init choose a proper handler or do other init based on the function name instead of its alias.
Using the Go language I am writing a function that uses a custom error variable, e.g.
func readEnv() (map[string]string, error) {
var ErrConfig = errors.New("Configuration Error: Variables starting with the right prefix are not even")
if this {
return nil, ErrConfig
}
I declare this as a local var to avoid declaring it as a package-level var which is not recommended (and marked as issue from the linter if I am not mistaken)
The problem arises when I want to unit test this fxn and want to also test the error path (in which case the fxn should return the above error which however has not access to.). Now, the only way I can think of to address this is to re-declare this variable in my table test.
Which is the right way? Declaring ErrConfig as a package-level variable or just re-declaring it in the unit test fxn?
Does it matter to the caller of readEnv() what error you return?
If it doesn't matter, your test shouldn't care either, just check if the returned error is nil or not.
If it matters, in your current solution callers can't do any better than you in your tests. If it matters and clients should be able to tell, you have to export some kind of mechanism to test / examine the returned error.
One solution is to move ErrConfig to a package level variable. This is accepted, used numerous places in the standard lib too, e.g. io.EOF, io.ErrClosedPipe.
This is not the only solution though. You could make Errconfig unexported (e.g. errConfig), and provide an exported function to test an error, e.g.:
var errConfig = errors.New("Configuration Error: Variables starting...")
func IsErrConfig(err error ) bool {
return err == errConfig
}
This is also used in many places in the standard lib, e.g. os.IsExist(), os.IsNotExist()
You could also make the returned error implement an exported interface, and callers can check using a type assertion if the returned error implements that, providing extra functionality for the returned error.
I am doing some web develoment using the go programming language using the package html/template. At some point of the code, I need to call the function template.ParseFiles(...) so I can create a template from those files ad then execute it using temp.Execute(w,data). I would like to know if it is better to create the template on each request or to do it once in the main and declare a global variable.
Right now I do it on each request on my handle functions, like most tutorials do. However, I don't know If I'm wasting resources by doing it on each request instead of having them as global variables.
This is how it looks on each request
func ViewStats(w http.ResponseWriter, r *http.Request) {
//Get stuff from db and put them in data
//...
//return data to user
tmp, err := template.ParseFiles("views/guest-layout.html",
"views/stats.html")
if err != nil {
fmt.Println(err)
} else {
tmp.Execute(w,data)
}
}
I would like to know if this is better:
var temp1 template.Template
func main() {
temp1, err = template.ParseFiles("file1","file2")
//...
}
As usual: It depends.
But first some nuance:
You should never do template parsing (or anything else interesting) in your main() function. Instead, your main() function should call methods (or a single method) that kicks off the chain of interesting things in your program.
Go doesn't have globals, so it's not actually an option to store your parsed templates in a global variable in the first place. The closest Go has to global variables is package variables. You could store your parsed templates in a package variable in the main package, but this is also bad form, as your main package (except for tiny, trivial programs), should just be an entry point, and otherwise nearly empty.
But now, on to the core of your question:
Should you parse templates per request, or per run?
And here it depends.
If you have templates that change frequently (i.e. during development, when you're constantly editing your HTML files), once per request can be best.
But this is far less efficient than just parsing once, so in production, you may wish to parse the templates once on startup only. Then you can store the templates in a package variable, or better, in a struct that is initialized at runtime. But I leave that to you.
But what may be best is actually a bit of a compromise between the two approaches. It may be best to load your templates at start-up, and re-load them occasionally, either automatically (say, every 5 minutes), or watch your filesystem, and reload them whenever the on-disk representation of the templates changes.
How to do this is left as an exercise for the reader.
I'm interested in using a Go package that uses a global variable which, for my application, is a key "variable". Each time I call this package, I want to set that variable (it's exported). And I'm calling it from various Go routines. Is there a recommended strategy for sequencing/syncing my calls to that package so that my code isn't colliding on that global variable?
Here's an example:
package main
import (
"fmt"
"sync"
"time"
"github.com/jameshaskell/_sketches/globalvars/testlib"
)
var wg sync.WaitGroup
func gr(i int) {
defer wg.Done()
testlib.GlobalVar = i
duration := time.Duration(i) * time.Millisecond
time.Sleep(duration)
fmt.Printf(" pause %d DONE\n", i)
fmt.Printf(" global var: %d should be: %d TestFunc: %s\n", testlib.GlobalVar, i, testlib.TestFunc())
}
func main() {
for i := 0; i <= 10; i += 1 {
wg.Add(1)
go gr(i)
}
wg.Wait()
}
The package I'm trying to access would be like:
package testlib
import "fmt"
var GlobalVar int
func TestFunc() string {
return fmt.Sprintf("GlobalVar: %d\n", GlobalVar)
}
NOTE: the package I'm hoping to use (having the global var) isn't mine...
Is this variable intended to be used this way? May be there’re some specific setters/getters for it? Does documentation have some info about?
I think code becomes very fragile because you do not control all accesses to the variable. You may serialize access from your code with a mutex. But another lib’s code doesn’t know about your it. Moreover it can change suddenly in new versions or bug fixes.
So I prefer:
To read about it in official docs
If documentation allows, and I can’t avoid to use it, protect access to the variable with sync/mutex/atomic/channel depending on a task.
Prepare tests to cover different cases with the variable
Run race condition detector as part of my CI tests.
You could use the atomic package, but beware the warning there:
These functions require great care to be used correctly. Except for
special, low-level applications, synchronization is better done with
channels or the facilities of the sync package. Share memory by
communicating; don't communicate by sharing memory.
Or you could use sync.Mutex to protect the variable but this would require wrapping it in a struct or an access function to properly control access.
There is a broader question though which you should attempt to answer - if you set this variable every time you access the package, why is it a package variable at all? Why not instead just pass it in to the function which needs it? Since it changes every time anyway, there's little point in a package variable quite apart from the synchronisation problems it poses.
Use the atomic package with the Value type