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 think it is no different from regular "if err != nil {}" handling, sorry
My thought behind ? is to make is working for a simple cases. If you are
doing an error translation/transform/wrapping - this is a case that I feel
is better handled by existing explicit "if err != nil" construct.
A.
"Users don't care about what the designer does. They care about what
they do. If every time you drove a car, you had to learn the meaning
of 100 knobs, the whole system wouldn't work. Simplicity comes from
tuning down the tasks required to drive the car into a certain set of
understood paradigms
On Mon, Jul 1, 2019 at 4:50 AM Michael Jones wrote:
> ... language design is about other people and other use cases than your own.
That nicely explains C++ existence.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
Thank you for sending that. That is a wonderful interview.
On Sun, 2019-06-30 at 19:49 -0700, Michael Jones wrote:
> With so many strongly worded emotional emails flying it might be
> helpful to
> remember that language design is about other people and other use
> cases
> than your own. The truly
With so many strongly worded emotional emails flying it might be helpful to
remember that language design is about other people and other use cases
than your own. The truly good answer meets the needs of many and harms few,
anticipates that no answer is final, and is flexible. Here is a nice way
I’ve developed systems that wrap checked exceptions in unchecked ones, but in
every case I can think of it was to “abort to the top” - returning control (or
exiting) - it is a specialized case of the re-throw, but I would argue it is
rarely used in anything other than framework type code, with
On Sun, Jun 30, 2019 at 5:23 PM robert engels wrote:
>
> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this
> behavior. Addressing the points from the Joeal article,
Checked exceptions address some of the difficulties with exceptions.
However, they introduce new
I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this
behavior. Addressing the points from the Joeal article,
Point#1
"They are invisible in the source code. Looking at a block of code, including
functions which may or may not throw exceptions, there is no way to see
I posted this question in SO, and was suggested to post here for more help:
--
I tried to link an existing C++ library to go code. The C++ library only
has a static library and a header file, no source code.
I used swigc to generate a libfoo.go and I wrote a simple libb.go
On Sun, Jun 30, 2019 at 4:16 AM robert engels wrote:
>
> I am not sure the ‘unexpected flow control’ concern is of the same importance
> as when this statement was first written, given paradigms like ‘reactive
> programming’ (I don’t like it, but it seems most others are not bothered by
> it).
On Sun, Jun 30, 2019 at 3:19 PM Jesper Louis Andersen
wrote:
> This is where the try-construct will definitely improve the ergonomics of the
> programming.
With full respect to you opinion and/or personal preferences,
"definitely improve" is just and only that. I _definitely_ don't share
that
Not sure where you read that. Anything can be sent on a channel. Even
channels can be sent over channels. That's often used when one goroutine
needs to reply to a message from another goroutine.
ne 30. 6. 2019 o 18:31 Sathish VJ napísal(a):
> I thought I read somewhere that functions cannot be
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 so the
incremental benefit is not high enough. A key component of exceptions is the
concept of ‘throws’ which is both self documenting, and requires
I thought I read somewhere that functions cannot be sent on channels. But
I tried it out and it can be. Play link:
https://play.golang.org/p/OeLpQsNwnCn
So, is there anything that cannot be sent on channels?
--
You received this message because you are subscribed to the Google Groups
Microsoft has suggested that Go change syscall.Open() to fix this. Please
pipe up if that might break your app!
Details quoted...
On Tuesday, June 25, 2019 at 8:25:24 AM UTC-7, Liam wrote:
>
> Microsoft recommends changing this, so we need to know whether existing
> apps rely on it:
>
> On
If you really care to "catch" errors, you want this:
https://github.com/golang/go/issues/27519
If all you need is to allocate a line to check an error and take an action,
you want this:
https://github.com/golang/go/issues/32611
But it's all moot. the Go team has told us we must prove that try
If good Go code handles or wraps every error, that code would never use
'try'. It seems weird to add a language feature that many codebases would
discourage the use of.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
I wrote a proposal with function-scope named handlers that uses a per-call
try flag and offers most features of 'catch', but it hasn't received any
attention...
https://github.com/golang/go/issues/27519
On Saturday, June 29, 2019 at 12:45:37 PM UTC-7, Robert Engels wrote:
>
> If you don’t
It seems to me that the try() mechanism could easily be undone by gofmt.
That is, if it does not work out it could be changed with low pain. This is
a virtue. Maybe the lesson is lost on some, but Go 1.0 was incompatible
with primordial Go and the Go team provided GoFix to mutate code. That was
On Sat, Jun 29, 2019 at 9:30 PM Henrik Johansson
wrote:
>
> I have a feeling that there is a quite large "silent majority" that pretty
> much agrees with me.
>
>
Go is a language with the following properties, among other things:
* Massive concurrency through a high amount of gorutines
*
Indeed.
I think many people like the proposal but are not vocal about it. It is not
perfect but it *does *bring value to the table if you read the proposal in
its entirety and think about how you would use/could use it in a real life
scenario.
I do *decorate *errors a lot, I do care about the
And a further example from the same blog post suggests:
ew := {w: fd}
ew.write(p0[a:b])
ew.write(p1[c:d])
ew.write(p2[e:f])
// and so on
if ew.err != nil {
return ew.err
}
This suffers from the same problem - you need to know the internals of
errWriter to understand the flow, and certainly
Just one other important point, I think the Go documentation makes the case for
exceptions. If you read the blog post https://blog.golang.org/errors-are-values
you’ll see this suggested code cited as a “better way”:
scanner := bufio.NewScanner(input)
for scanner.Scan() {
token :=
I am not sure the ‘unexpected flow control’ concern is of the same importance
as when this statement was first written, given paradigms like ‘reactive
programming’ (I don’t like it, but it seems most others are not bothered by it).
I am curious more though in the belief that exceptions are
I fixed the importing issues people were having with version of Go newer
than 1.10.
If you haven't tried the generics tool yet and you're interested, now it
should work for you!
It's a tool that takes a Go file which uses generics and translates it into
a regular Go code that you can run. It
ma·jor
/ˈmājər/
adjective
• 1.
important, serious, or significant.
so I’ll apologize for my transpose, and I’ll ask it in your exact words, please
name a significant new project in the last 2 years that wasn’t written in Java
or C++ because it seems by your quote
> Fortunately for
On Sat, 29 Jun 2019 22:09:10 -0700 (PDT)
Lucio wrote:
> a lot of people have presumably realised that the consequencesof tackling
> the verbosity of the current iteration of error handling comes with a big
> price tag.
I personally am in horror I would lose the clear sight of the flow.
Current
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
Hello
Finaly, Isegal helps me to solve this problem. You can have a complete
description on how to proceed here:
https://github.com/golang/go/issues/32851
Le dimanche 23 juin 2019 13:49:33 UTC+2, nobody nobodye a écrit :
>
> Hello,
>
> I need some assistance to export a GO dll function to a C
On Sat, 29 Jun 2019 18:25:37 -0500
Robert Engels wrote:
> What exactly are you basing your incorrect opinions on?
> When you use terms like ‘major’ do you mean important,
> infrastructure critical, number of users, number of developers?
> Maybe as a frame of reference you can name a single
>
31 matches
Mail list logo
