Totally not a go programmer but here are my worthless two cents.
I don't see anything wrong with the try catch paradigm, you can choose your
granularity. If you want to check every call then you can, if you want to
let a few cluster together you can. You guys make is sound like go style
error handling is the only way to catch errors at every step. That's not
true at all.
Surely something can be done about the boilerplate if err != nil maybe
shorten that to iferr or something like that. In fact why can't "err" be a
language construct where you raise something and it goes into an err[]
array. At any time you can check to see what's in there. That would clean
up the code so much.
result = doSomething()
iferr {
error = err.pop()
}
Isn't that so much more readable?
You could even create checkpoints
raiseErrors()
// from now on all errors are raised and the program halts
do()
some()
tasks()
collectErrors()
// from now on program doesn't halt but err[] array is populated
do()
other()
things()
dealWithErrArray() // it's global so need to pass it in
raiseErrors()
// back to raising them.
As I said none of these are particularly nice. Elixir gives you both ways
def register({email, password}) do
{:ok, pid} = Membership.connect()
sql = "select * from membership.register($1, $2);"
case Postgrex.Connection.query(pid, sql, [email, password]) do
{:ok, res} ->
cols = res.columns
[first_row | _] = res.rows
[new_id, validation_token, auth_token, success, message] = first_row
{:ok, %RegistrationResult{
success: success,
message: message,
new_id: new_id,
authentication_token: auth_token,
validation_token: validation_token
}}
{:error, err} -> {:error, err}
end
end
try do
opts
|> Keyword.fetch!(:source_file)
|> File.read!
rescue
e in KeyError -> IO.puts "missing :source_file option"
e in File.Error -> IO.puts "unable to read source file"
end
As somebody who has just started learning go I can't find any justification
for the insane amount of boilerplate go error handling inflicts on the
programmer. Surely there is a a better way.
On Wednesday, September 6, 2017 at 8:54:38 PM UTC+12, Henry wrote:
>
> I use what I would call as *error context*.
>
> Here is the simple definition of the *error context*:
>
> type ErrorContext interface {
> ContainsError() bool
> SetError(err error)
> Error() error
> }
>
> Here is how you would use it inside the error-prone function:
>
> func FragileFunction(ctx ErrorContext) {
> if ctx.ContainsError() {
> return
> }
>
> //some processing ...
> //if there is an error
> ctx.SetError(errors.New("some error"))
> return
> }
>
>
> It allows you to do this:
>
> ctx := NewErrorContext()
>
> fridge := GetFridge(ctx)
> egg := GetEgg(fridge, ctx)
> mixedEgg := MixAndSeason(egg, ctx)
> friedEgg := Fry(mixedEgg, ctx)
>
> if ctx.ContainsError() {
> fmt.Printf("failed to fry eggs: %s", ctx.Error().Error())
> }
>
> Or you can even do this:
>
> ctxA := NewErrorContext()
> ctxB := NewErrorContext()
> ignored := NewErrorContext()
>
> a := DoSomethingOne(ctxA)
> b := DoSomethingTwo(a, ctxA)
> c,d := DoSomethingThree(b, ctxB) //different context
> if ctxB.ContainsError() {
> c = 1
> d = 2
> }
> e := DoSomethingFour(c, d, ctxA)
> if ctxA.ContainsError() {
> fmt.Println("Failed To do A")
> }
>
> DoSomething(e, ignored) //error is ignored
>
> It is up to you how you would implement the error context.
>
>
> On Tuesday, September 5, 2017 at 1:27:20 AM UTC+7,
> marti...@programmfabrik.de wrote:
>
>> Hi guys,
>>
>> at first I though I really like the idea of how Go deals with error
>> management and handling, but the more Go code I look at or try to program,
>> the more I get scared about checking errors every second line in every
>> given block of code.
>>
>> Take a look at this example here from "Build Web Application with Golang":
>>
>> // insert
>> stmt, err := db.Prepare("INSERT INTO userinfo(username, departname, created)
>> values(?,?,?)")
>> if err != nil {
>> // handle error
>> }
>> res, err := stmt.Exec("astaxie", "研发部门", "2012-12-09")
>> if err != nil {
>> // handle error
>> }
>> id, err := res.LastInsertId()
>> if err != nil {
>> // handle error
>> }
>> fmt.Println(id)
>> // update
>> stmt, err = db.Prepare("update userinfo set username=? where uid=?")
>> if err != nil {
>> // handle error
>> }
>> res, err = stmt.Exec("astaxieupdate", id)
>> if err != nil {
>> // handle error
>> }
>> affect, err := res.RowsAffected()
>> if err != nil {
>> // handle error
>> }
>>
>>
>> Seriously? And yes, I have read
>> https://blog.golang.org/errors-are-values...
>>
>> The best case reduction I found is:
>>
>> ...
>> res, err = stmt.Exec("astaxieupdate", id)
>> checkError(err)
>> ...
>>
>> Still, I need this after each line of calling a function which may return
>> an error.
>>
>> I bet this is not pleasant to do in larger code bases and it also takes
>> away focus from what is actually happening.
>>
>> 50-80% of all lines of code in my example deal with error handling?
>>
>> This is not good. Seriously.
>>
>> And don't get me wrong, there is a lot of things I really like, love and
>> adore about Go, but catching errors needs an improved syntax!
>>
>> And I am not proposing try...catch here.
>>
>> How about introducing a new piece of syntax
>>
>> "watch if .... "
>>
>> which tells the compiler to watch out for changes in a given SimpleStmt
>>
>> The same code as above would look like this:
>>
>> var err Error
>>
>> watch if err != nil {
>> // handle error(s)
>> }
>>
>> // insert
>> stmt, err := db.Prepare("INSERT INTO userinfo(username, departname,
>> created) values(?,?,?)")
>> res, err := stmt.Exec("astaxie", "研发部门", "2012-12-09")
>> id, err := res.LastInsertId()
>> fmt.Println(id)
>>
>> // update
>> stmt, err = db.Prepare("update userinfo set username=? where uid=?")
>> res, err = stmt.Exec("astaxieupdate", id)
>> affect, err := res.RowsAffected()
>>
>>
>> - The "watch if" would be executed after each assignment of any of
>> the variables used in SimpleStmt of the statement.
>> - Multiple "watch if" would be executed in order or appearance
>> - The "watch if" could be used like "defer..." inside functions
>> - The "watch if" would work in its full scope of the watched variables
>>
>> I am not a language expert, so may be there is a saner way of expression
>> what I want to achieve.
>>
>> But bottom line is, there should by an easier to read and write way to
>> deal with errors in Go.
>>
>>
>> Martin
>>
>>
>>
>>
>>
>>
--
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
