Things that don't translate between PHP and Go... about pgo

[protosam]

@arthurkushman here's some of my thoughts, hopefully they help.

In regards to error handling, you're really just going to have to return all errors as type error, an additional value. For example:

import "errors"

...

func myfn(str string) (string, error) {
	if str == "hello" {
		return str, nil
	}
	return "", errors.New("Input to myfn(string) must be hello!")
}

Handling errors for inputs that are possibly not integers should probably be done like:
Ref: https://github.com/arthurkushman/pgo/blob/master/pfiles.go#L54-L56

if !okOff || !okLim {
	errmsg := fmt.Sprintf("Error on passing params with wrong types to FileGetContents: offset %T and limit %T", args[1], args[2])
	return nil, errors.New(errmsg)
}

Having a variable name matching the name of a datatype in any language leads to confusion, especially when it comes to new people maintaining your code later. I still recommend renaming it, because as-is it would only make detailed code documentation confusing or even confuse someone reading through the code that's fresh into the language coming from another language. It's regarded as bad style and this is just one of the reasons many languages wont even allow you to do this.

Whenever you run your printError() function it still has very bad side effects: https://github.com/arthurkushman/pgo/blob/master/core.go#L26-L28
Consider that your application should never exit, if it's supposed to be a web server using the http library. If someone just forgets to handle some input somewhere and an error occurs in many of your functions, os.Exit(1) will close the entire program and the developer of that web app is left with a down website where only 1 small feature may have just been broken for a night.

In PHP where it's fine for you to die() whenever, because script execution runs only once per page load.

In contrast when you write web apps in Go, Ruby, Python, etc. you're making a daemon that continually runs. die() are not good for these use cases. Any API or library assuming that it should be doing process level stuff that could immediately stop an application is really bad in these scenarios and should only return errors for the developer to handle in his own code.

[arthurkushman]

Excellent, thank u for this check-list, I really appreciate your contribution for opening this issue.
Let's try to re-check:

• If you're writing a web app in go, you don't want your route to panic the entire application. This results in the site is down. Error handling does not translate between php and go. You have to just handle your errors. - Done with fmt.Printf() and os.Exit(1)

• You're not handling potential type errors that could arise if that isn't an integer.

Fixed - now it is checked with type int

• What if your file contents aren't even long enough for this?

Then an error will be returned and printed as stated in

func (b *Reader) Discard(n int) (discarded int, err error) {

description: // If Discard skips fewer than n bytes, it also returns an error.

• ... variable name is variable type, rename that var...

Done as it is logically correct to save from further misspellings, misuses etc

Thx again and hope someday u will use it in production env, but at this moment this repo doesn't even have semver for that. I will definitely push this work further and try to cover all cases, then release 0.x.x versions that still do not recommended for use in prod env, only for developers own risk (if they don't mind for some reason), as it is a common practice to create any software in the world (with 0 zeroed semVers etc), it seems there is no point for "but I wouldn't run any of this in production" comment.

[arthurkushman]

I've done as much as I could while finding time between pjs, if there will be any proposals - will be glad to move forward with better dev practices. Thx