> > Transaction can give an error for different reasons, and I want to give > the client a wide choice. Probably, the financial features are to blame for > this ...
I agree with having switchable errors but usually this is done with vars of types that implement the error interface. For example sql.ErrNoRows: https://github.com/golang/go/blob/release-branch.go1.9/src/database/sql/sql.go#L305, and here’s the blog post: https://blog.golang.org/error-handling-and-go Replace the word "log" with the word "go"? It seems to me, "log" better > reflects the meaning, eh? I meant put the go keyword into the log function so it can be concurrent and just be a function call. "Log()" instead of "go Log()". > While they remain structures, as instead of a mutex, there may appear > spinlocks or something else. > But I did not know about the transfer of mutexes, can you give examples? Maybe it’s not that different, but I personally prefer the readability of not having a pointer for method receivers. type SyncMapStruct struct { *sync.Mutex Data map[string]int } func (a SyncMapStruct) Access(value string) int { a.Lock() defer a.Unlock() return a.Data[value] } In your opinion, what level of my code, how would you rate it? The tests are good to have, but maybe the API could be better. It seems professional to me. Thanks for sharing transaction here. Matt On Thursday, February 1, 2018 at 2:36:43 PM UTC-6, [email protected] wrote: > > Matt, thank you, you took the time to review my code, I appreciate it. > > > Usually on GitHub the license is in LICENSE, not LICENSE.md > <http://license.md/>. > > Yes, added .md by analogy with README.md <http://readme.md/> > > core_public.go, transaction_public.go could just be core.go and > transaction.go. > > And I wanted to write core_api.go )) > > The Core type is a code smell to me because it doesn’t represent anything > specific. Perhaps there’s a need for multiple concurrent Cores. The type > seems overloaded to me > > I agree, the name is not informative. And the type is undoubtedly > overloaded - a too large monolith. Later I'll think of something. > > Why have errorCodes instead of error? Usually a nil would be returned > instead of Ok. > > Transaction can give an error for different reasons, and I want to give > the client a wide choice. Probably, the financial features are to blame for > this ... > > Example: > > // transaction > switch res := tr.Begin().Credit(123, "USD", 5).End(); res { > case tn.Ok: > fmt.Println("Done! Account cleared") > case tn.ErrCodeUnitNotExist: > fmt.Println("Unit not exist") > case tn.ErrCodeTransactionCatch: > fmt.Println("Account not catch") > case tn.ErrCodeTransactionCredit: > fmt.Println("Such a unit already exists") > default: > fmt.Println("Unknown error") > } > > I haven’t seen this logging pattern before, interesting. Why not have the > go keyword in lgr.log? > > Replace the word "log" with the word "go"? It seems to me, "log" better > reflects the meaning, eh? > > Also lgr could be an embedded field so you could call c.log instead of > c.lgr.log. > > Good idea! > > I haven’t seen runtime.Gosched() before but maybe that’s a tool I’ll use > sometime. > > To implement the lock-free algorithm, this is a convenient solution in a > situation where the resource is blocked and you have to wait in the loop > > The logger may be more efficient as a slice. As a map you don’t need to > hold a pointer to it in Core (maps are represented as a pointer value). For > send() the %v printf formatter makes the type switch unnecessary. > > Still, I want to leave the map to have the keys. I hope that the > efficiency of the logger will not be important, since errors will be rare. > I hope very much)) > > Why not “type storage [storageNumber]*section” instead of the struct? > > True, the locks were gone, but the structure was left ... (( > > A section and unit could have a *sync.Mutex and then be passed by value > instead of by pointer. > > While they remain structures, as instead of a mutex, there may appear > spinlocks or something else. > > But I did not know about the transfer of mutexes, can you give examples? > > Is type Account meant to be exported? There are no methods and it’s not > used anywhere public. > > Right, thanks. > > In your opinion, what level of my code, how would you rate it? > > Thanks for the detailed and useful review! > > четверг, 1 февраля 2018 г., 18:16:56 UTC+3 пользователь > [email protected] написал: >> >> Hi Eduard, here’s a code review. >> ... >> >> On Thursday, February 1, 2018 at 2:41:58 AM UTC-6, Claygod wrote: >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
