> I am using flutter and so Dart for the frontend right now, and I have
come to a
Error context has a little value in the end user apps, I noticed this too
at the example of just CLI utilities. It is totally different when it comes
to modern network systems, because there're far more places of
Dear,
On Mon, Aug 31, 2020, 4:16 AM Zakaria bin Haris wrote:
> Hi, gophers!
>
> Idk if this has been proposed or discussed before.
>
> Given the last error handling abbreviation proposal is rejected. How about
> some simple syntactic sugar like this:
>
> *rin* Something()
>
I love the consist
I read the try proposal and they're quite different from my simple
suggestion which is just a statement.
Pada tanggal Sen, 31 Agt 2020 14.02, Axel Wagner <
axel.wagner...@googlemail.com> menulis:
> Oh, sorry: I mixed the history up.
> AIUI this is the same as the try proposal with a different key
On 2020-08-31 03:34, Ian Lance Taylor wrote:
>> Idk if this has been proposed or discussed before.
>>
>> Given the last error handling abbreviation proposal is rejected. How about
>> some simple syntactic sugar like this:
>>
>> rin Something()
>>
>> Which is just a sugar for:
>>
>> if err := S
On Mon, Aug 31, 2020 at 3:31 PM Zakaria wrote:
> If the objections on the too magical handle part, why not cut that part
> and retain the check part?
>
> Most of the time the we just forward the error on to the next level
> anyway. Handling error is rarely done and should be explicit.
>
It's imp
On Monday, 31 August 2020 06:32:09 UTC+1, Zakaria wrote:
>
> If the objections on the too magical handle part, why not cut that part
> and retain the check part?
>
> Most of the time the we just forward the error on to the next level anyway.
>
Often, good error handling requires replacing the err
Oh, sorry: I mixed the history up.
AIUI this is the same as the try proposal with a different keyword and
*that* got rejected for the "magical" control flow.
On Mon, Aug 31, 2020 at 9:00 AM Axel Wagner
wrote:
> On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote:
>
>> If the objections on the too mag
On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote:
> If the objections on the too magical handle part, why not cut that part
> and retain the check part?
>
The objection was mainly on the too magical check part, AIUI.
>
> Most of the time the we just forward the error on to the next level
> anyway
If the objections on the too magical handle part, why not cut that part and
retain the check part?
Most of the time the we just forward the error on to the next level anyway.
Handling error is rarely done and should be explicit.
I got better keyword for this: reterr
A portmanteau of return error.
On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris wrote:
>
> Idk if this has been proposed or discussed before.
>
> Given the last error handling abbreviation proposal is rejected. How about
> some simple syntactic sugar like this:
>
> rin Something()
>
> Which is just a sugar for:
>
> if err
Hi, gophers!
Idk if this has been proposed or discussed before.
Given the last error handling abbreviation proposal is rejected. How about
some simple syntactic sugar like this:
*rin* Something()
Which is just a sugar for:
if err := Something(); err != nil {
return err
}
To make it
11 matches
Mail list logo
