In support of Handle Chaining; On Check

1 - Handle Changing.md

Handle Changing

I am in favor of the fact that the handle keyword has the ability to chain, as this allows for the ability to, for example, print variables that were used previously that are the actual root cause of the error instead of just dealing with the symptoms of the problem.

2 - On Check.md

On Check

The largest issues that I have with the current suggested form of check is that of ambiguity and code legibility in agreement with Alessandro Arzilli. When using the check keyword, the goal is to simplify err. I believe that the current format would be better formatted for legibility as either an explicit function call “check(exampleFunc(...))” similar to make. I would also be in favor of converting catch to a single character operator “? exampleFunc(..)” or “exampleFunc(..) ?”. I am for the latter as I believe that would be the cleanest and fastest addition and to existing code, as well as allow for the syntax “err?”

On the simple existence of some from of optional removal of err from returns, I am if favor of it as it cleans the work around that I had to use that resulted in this (incorrect) error report. golang/go#27263

Edit: After reading a number of other responses, I feel that any from of check NEEDS to be optional. Under that case, it is possible for a programmer to use both “if err != nil” and “check”, thus resulting in the clearest code under any situation.

3 - For consideration.md

For Consideration

It may be worth considering if entire code blocks can have check (or ?) applied to them to act as a catch for any and all internal function that return an error but are not dealt with inside the block

For example

	V1 = Check func1(...)
	Check func2(...)
}

Could become

Check {
	V1 = func1(...)
	func2(...)
}

This would allow for functions with similar inputs to not require repetitive checks in the same from as imports.

Converted from Google Doc to Gist for better communication and response.

A single character operator may be too terse for this purpose. It may be easily missed in large code-bases where it may be important to distinguish between which errors are being checked in order to determine root-cause.