... is awesome. so much better to read. much much more enjoyable.
Thank you!
--
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...@googlegroup
yes the zero value test seems akward from here also.
It appears to me the proposal is sub optimal because,
to put it clear, the operator is dumb.
Its a disguised if with a one lin block statement.
I believe it would gain a ton more usability by being smarter to allow for
more useful predefined/e
I made regarding the errors as values blog clearly
> demonstrates the significant problems with the current approach.
>
> On Jul 3, 2019, at 8:23 AM, mh cbon >
> wrote:
>
> but exceptions are shit. even the typed catch/final statements are a
> workaround.
>
> On Sunda
but exceptions are shit. even the typed catch/final statements are a
workaround.
On Sunday, June 30, 2019 at 7:03:49 PM UTC+2, Robert Engels wrote:
>
> I think both of the proposals are fine, but they suffer from the “lack of
> completeness”. In that, they improve things, but don’t go far enough
f := file.Open() ? error {
//f is nill
return erors.Wrap("nop",err)
}
defer f.Close()
On Saturday, June 29, 2019 at 11:56:09 PM UTC+2, Andrey Tcherepanov wrote:
>
> Hello mighty fighters of errors!
>
> Here comes my half-thought idea of another way to express error handling:
>
> *Add a postfix '?'
https://2019.www.torproject.org/docs/tor-onion-service.html.en
free, no cc required.
On Monday, May 27, 2019 at 8:01:38 PM UTC+2, aimar wrote:
>
> Hi,
>
> My teacher has asked me to develop an API with Golang and test it on the
> web instead of localhost. I was thinking of github.io but then I f
