17 ms·
Introducing HTTP Tracing
- fbreduc 10y agoevery time err != nil take a drink
- oldmanjay 10y agoEvery time I find code where people skipped checking for errors, I want to drink
- eropple 10y agoWhen you're using a language with generics and flexible syntax, you just use the Try pattern and you never aren't checking for errors.
- oldmanjay 10y agoAnd when working in a language that returns errors, you just use the "check the result for an error" pattern and same.
- eropple 10y agoOne of these things is a compiler-enforced piece of tooling; I know my errors are handled because I don't have any alternatives to handling them. The other is a code standard that people regularly ignore. If you want to assert equivalence between these two options, I suggest you show your work.
- oldmanjay 10y agoIf you have to use a pattern, how is the compiler enforcing it? Suppose you don't use the pattern? Since you spoke only in the abstract without so much as naming your language, I'd suggest your work exhibition should come first.
- winter_blue 10y agoIn languages like Java, with checked exceptions, you are required by the compiler to have a try-catch block that handles the checked exception at some point, or you have to add "throws FooException" to your function, which passes over the error-handling responsibility to callers of that function. Stack unwinding (with 'finally' clean-up blocks) results in higher brevity and relatively cleaner code than having a err != null check after every function call. Not to say, checking err != null is optional, could be accidentally forgotten, and cause unpredictable runtime behavior.
- eropple 10y agoThis is true, but I was referring to something like Scala's Try[T] (which wraps Java's exceptions and returns either the value T or the exception caught, and allows you to chain Try calls together through `map()`, `recover()` from them as appropriate, etc.) or Rust's Result<V, E>.
- jonaf 10y agoI agree with this except for two cases, which I would LOVE counter arguments for. Case 1: checked exceptions. This is what Java used heavily in the early days, a bit less today, which basically requires you to deal with known exception scenarios. It was good because it wouldn't compile unless you explicitly said "I'm not dealing with this" or you dealt with it. But its bad because it requires your methods to throw some list of exceptions all the way up the call stack. I think there are some other problems that Experts(tm) around here can probably point out better than I. Still, checked exceptions seem to be a valid pattern in some contexts, and this feels like the same pattern Go follows. That said, I dislike Go's error handling for the same reason: my code is really cluttered and unclear this way. Case 2: when you catch everything, you may not throw the right thing to your caller(s). Even worse, you may swallow an exception unintentionally and leave callers hanging in the balance. It's not that it's impossible or particularly difficult to avoid making these mistakes by wrapping everything in a Try[T], just that it's easy to make the mistake of catching more than you intended.
- 10y ago
- Zikes 10y agohttps://play.golang.org/p/X6zItReejE https://play.golang.org/p/X6zItReejE > tmp/sandbox459432416/main.go:10: err declared and not used Go won't compile unless you handle your errors.
- cderwin 10y agoTo be fair, removing the assignment altogether in your example ignores the error much less explicitly than `try { myFunc(); } except { pass; }`
- Zikes 10y agoIf you remove the err assignment the compiler will also complain about a value assignment mismatch: https://play.golang.org/p/UBL0MZtscc https://play.golang.org/p/UBL0MZtscc > tmp/sandbox307381845/main.go:8: multiple-value "html/template".New("foo").Parse() in single-value context You would have to explicitly assign the err return value to underscore in order to ignore it.
- hueving 10y agoNo, remove the entire assignment.
- cderwin 10y agohueving is correct, I meant something like this[1]. Of course, something like this[2] also works. [1] https://play.golang.org/p/igdUx6qckf https://play.golang.org/p/igdUx6qckf [2] https://play.golang.org/p/_JW5QE_zOJ https://play.golang.org/p/_JW5QE_zOJ
- Zikes 10y agoThat function does not have side effects, so it would be pointless to remove the assignment altogether. Assigning errors to underscore is effectively the same as try { myFunc(); } except { pass; }, making them equivalent.
- taeric 10y agoI wouldn't make that strong of a claim. I've seen plenty of code in the try pattern that, basically, didn't check for errors.
- wtbob 10y agoIn fairness, conditions and restarts could do the same job and would be more readable.
- rakyll 10y agoThere are only two err != nils in the article. What's your point?
- justinsb 10y agoFour, actually, but two have been removed for brevity.
- rakyll 10y agoTwo. The URL is a constant that is guaranteed not to return an error. It is not brevity. Anyways, the point is I don't understand the point of err != nil bashing here, given there are two programs in the article that only contain one error check each.
- ben_jones 10y agoAs someone who writes a lot of Go I have mixed feelings about it. The problem is that there are implicit errors regardless and the explicitness in err != nil tricks beginners into thinking that they've covered all edge cases, they haven't. Recover() is probably the only way to handle internal panics and even then it only works if you know to that internal call might call panic(). That said I can't think of an alternative other then to reduce the number of panic()s hidden in various libraries.
- rakyll 10y agoAvoiding error checking against a properly formatted constant is not avoiding error checking. I cannot follow your argument.
- ben_jones 10y agoSorry, I guess I'm not really making one. If anything I'm commenting that (IMO) explicit error handling isn't as explicit as people thing it is. There are internal errors induced by panic() that are really inconvenient.
- deleted 10y ago[deleted]
- buckhx 10y agoI haven't explicitly needed HTTP tracing yet, but am glad to see it's added to the tool set specifically for debugging DNS which can be tough. On another note, it's pretty f*cking lame that the only discussion in this post is a tangent about error checking and not even remotely related to the content.
- Karunamon 10y agoIs it bad that the first thought that came to mind upon reading the example code on the page is "Wow, this is ugly"? ...And I don't mean the "if err" sprinkling that has a whole subthread, I mean the actual layout of the code. It's not hard to understand just.. ugly. Aesthetically. And it's hard for me to put my finger on why.. maybe it's the symbols everywhere. I was about ready to make a remark about how I hope that's not idiomatic go code, but no, this is from the official site. I've never wanted to like a language that makes me not want to like it as much as Go, and that's the god's honest truth.
- zenlikethat 10y agoGive it a chance. I feel the opposite in many cases today because of two reasons: static typing and gofmt. In Python code I frequently find myself playing "what the hell are these objects" or "what the hell does this overloaded operator do" and in lower level code (esp. C++) it looks like a mangled jaggy mess. Linux kernel code is one of the few exceptions due to the strict style guidelines.
- icholy 10y agolots of time I see people compromise readability to chase this "beauty" and "elegance". Go makes this practically impossible.
- hueving 10y agoPython is pretty readable but it doesn't look like someone smashed the keyboard while holding down the shift key.
- tpl 10y agoI wonder if this will help any of the opentracing work? Cool to see this added as a first class citizen.
- Karupan 10y agoGreat to see this as part of the core language! Say what you will about Go, the core libs and tools are well designed and really useful.
- ejholmes 10y agoThis has been one of my favorite new additions to Go 1.7. Incredibly useful for debugging persistent connection pool efficiency.
- aleem 10y agoHTTPStat https://github.com/davecheney/httpstat https://github.com/davecheney/httpstat now uses the HTTP Tracing library to provide some pretty neat graphs, letting you visualise the HTTP Tracing output. $ httpstat https://news.ycombinator.com HTTP/1.1 200 OK Date: Wed, 05 Oct 2016 05:23:28 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Vary: Accept-Encoding Cache-Control: private X-Frame-Options: DENY Cache-Control: max-age=0 Strict-Transport-Security: max-age=31556900; includeSubDomains Server: cloudflare-nginx CF-RAY: 2ece7111d9ba29c4-MCT DNS Lookup TCP Connection SSL Handshake Server Processing Content Transfer [ 5ms | 152ms | 508ms | 1285ms | 226ms ] | | | | | namelookup:5ms | | | | connect:157ms | | | pretransfer:665ms | | starttransfer:1950ms | total:2176ms
- ubercow 10y agoThis looks awesome. Will have to check this out tomorrow.