As sad as it sounds, inside of me I agree on "it is all moot anyway",
but... Aren't we allowed to at least freely day-dream anyway :) ?
I was thinking about it over weekend, and came with these "rules", but I
need help on these for sure
1. If expression ends with ? (like func()?) , then it
Erm, what expression besides a function call would yield an error only
sometimes? I suppose channel receive, but is that a useful case?
It's all moot anyway.
On Mon, Jul 1, 2019, 10:42 PM Andrey Tcherepanov <
xnow4fippy...@sneakemail.com> wrote:
> Thanks Liam,
>
> your suggested placement would
Thanks Liam,
your suggested placement would make it somehow impossible (or at least I
cannot see it right now) to use with someExpression?.someMember
If I am not mistaken, yours is close to the currently proposed "try", just
replacing it with ?, am I right on that ?
A.
On Monday, July 1, 2019
I've noted in several places that a 'try' expression (via keyword,
built-in, or symbol) is suitable only when the function is expected to
always succeed, and so would panic on error.
Also the symbol, which I agree is preferable, works best this way
will?(always?(work?())) vs will(always(work()?
Thank you Michael.
I honestly never looked at it from a human-language prospective! Maybe
because 25+ years of interacting with programming languages made me a bit
deaf to the sound of it, and my head is kind of translating it back and
forth transparently. To think of it, it might explain why I
My personal thought, though it may seem strange, is that the best argument
for it lies in the single word sentence at the bottom of your email. You
write "Thoughts?" -- and that is very expressive in English in just the way
that you mean above in your examples. I don't know enough other languages
t
Hello mighty fighters of errors!
Here comes my half-thought idea of another way to express error handling:
*Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND an
error for nil. *
(Denis have shred it to pieces already in
https://github.com/golang/go/issues/32852. Thank you
