|
HFX posted:Unless you have a subdomain of a subdomain. So modelenv.test.example.com will fail. you can do that? is that even valid?
|
# ? Jul 13, 2017 18:12 |
|
|
# ? Jun 5, 2024 20:10 |
|
curufinor posted:you can do that? is that even valid? Absolutely. You should see some of the poo poo my flatmate and I got up to with some cheap domains and each other's reverse DNS when we both worked at the same ISP.
|
# ? Jul 13, 2017 18:15 |
|
HFX posted:Unless you have a subdomain of a subdomain. So modelenv.test.example.com will fail. That too, but I hope by the time someone's two layers deep they know what they're doing but who am I kidding... curufinor posted:you can do that? is that even valid? At some point you're gonna wildcard that junk and let nginx pass it all to some backend that is just treating the leading subdomain like any other URI fragment. It's very stylish. Ranzear fucked around with this message at 18:35 on Jul 13, 2017 |
# ? Jul 13, 2017 18:31 |
|
HFX posted:Unless you have a subdomain of a subdomain. So modelenv.test.example.com will fail. https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/#certificates
|
# ? Jul 13, 2017 19:24 |
|
Eela6 posted:What, seriously? What exactly are you planning to do if closing a file fails? EINTR is the only runtime error that it can hit that can be handled, and anything higher level than a raw syscall should be doing that for you.
|
# ? Jul 13, 2017 21:11 |
|
Plorkyeran posted:What exactly are you planning to do if closing a file fails? EINTR is the only runtime error that it can hit that can be handled, and anything higher level than a raw syscall should be doing that for you. If nothing else, display the error to the user or log it? Silently failing to save the data you were expecting to save isn't a good thing. Observably failing is at least better.
|
# ? Jul 13, 2017 21:29 |
|
Failing to close a file doesn't mean that the data isn't on disk.
|
# ? Jul 13, 2017 21:43 |
|
But it could mean its not all on disk. Maybe you want to check if the close fails and you want to verify the write occurred. Or maybe you're using a remote file system thing like the article that spawned this discussion with the same interface where the file actually wasn't written, silently. edit: from the same article, about close(2) on linux: quote:Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota.
|
# ? Jul 13, 2017 21:47 |
|
necrotic posted:But it could mean its not all on disk. Maybe you want to check if the close fails and you want to verify the write occurred. That's what fsync is for. Plorkyeran posted:What exactly are you planning to do if closing a file fails? EINTR is the only runtime error that it can hit that can be handled, and anything higher level than a raw syscall should be doing that for you. Do not try to handle EINTR on close on linux. close will always close the file descriptor on Linux.
|
# ? Jul 13, 2017 21:48 |
necrotic posted:you're using a remote file system thing like the article bingo.
|
|
# ? Jul 13, 2017 21:50 |
|
I actually ran into an issue kind of like this yesterday with a builder class that creates a file on construction and batches writes because it used a remote file system. The object's destructor obviously closes the file, which causes a flush. My bug was that something else was deleting the file, and that would only show up at close time.
|
# ? Jul 13, 2017 22:08 |
|
b0lt posted:That's what fsync is for. Does go's File.Close fsync for you? Because I don't see any of the examples on using it talking about fsync. And then you run into the issue of fsync failing in a defer, or having to do what the article did with a wrapper to handle it all anyway. edit: and if close fsyncs then that could fail so we're back at square one.
|
# ? Jul 13, 2017 22:10 |
|
The idea is that you fsync and actually get told about any errors before you close.
|
# ? Jul 13, 2017 22:47 |
|
bigmandan posted:Most web servers should support some sort of redirection configuration to handle this. It's a lovely work around though. Chances are it'll never get to the webserver because there's no A record defined for the domain. My 2nd job had a Sys Admin pushing back about adding an A record and pointing it at the www machine.
|
# ? Jul 13, 2017 23:10 |
|
rjmccall posted:The idea is that you fsync and actually get told about any errors before you close. yes, I know that. The (official) go examples about using files never do this is all I'm saying. Here's the blog post about the release of defer which doesn't even mention the potential issue here: https://blog.golang.org/defer-panic-and-recover
|
# ? Jul 13, 2017 23:12 |
|
comedyblissoption posted:https://hackernoon.com/correct-error-handling-is-hard-307ea72759c7 I'm not sure how Go especially lets you ignore errors. Errors are values and Go doesn't force you to do anything with them in particular, it just stuffs them in your face at all times to remind you. In other languages, you write similar code like `file.open` and without putting try-catch around it, you are able to ignore the errors effectively. Unless you're talking about a run-time error catching it for you, such as a segmentation fault; Go will panic appropriately on those defer statements as well. The only point of defer is to guarantee some code is executed whenever the function finishes execution. If you wanted to make sure the result of close was checked and threw an error, you could always say code:
Error handling is hard because given all errors that result from an operation, only a few of them are the error causer while the others are "knock-on errors", or errors caused by other errors or re-interpreted in other error contexts. Go's error interface is not good at actually helping you find the error causer (perhaps in the form of stack trace) and instead you end up comparing to domain specific errors like `io.EOF` or, god-forbid, comparing error strings. That sucks, but the ability to work with errors in your code without being required to throw signals all over the place ala C and Java is actually quite nice.
|
# ? Jul 13, 2017 23:15 |
|
rjmccall posted:The idea is that you fsync and actually get told about any errors before you close. Exactly. You want to have code in something like the following pattern: code:
|
# ? Jul 13, 2017 23:18 |
|
I guess that the "Go way" to do this properly would be to make defer into a block statement, kind of like an if statement:code:
|
# ? Jul 13, 2017 23:22 |
|
TooMuchAbstraction posted:I guess that the "Go way" to do this properly would be to make defer into a block statement, kind of like an if statement: I'm not sure if this is different from code:
or not. Another questionable way to do this is with named result parameters of course: code:
Coffee Mugshot fucked around with this message at 00:04 on Jul 14, 2017 |
# ? Jul 13, 2017 23:57 |
|
Coffee Mugshot posted:I'm not sure if this is different from It's not. Just prettier. And lord knows prettiness is not a high priority for the Go language developers.
|
# ? Jul 14, 2017 00:41 |
|
JavaScript code:
|
# ? Jul 14, 2017 01:11 |
|
JewKiller 3000 posted:go is the donald trump of programming languages: someday everyone is going to simultaneously realize that it's garbage, and the retards who went along with it will lose all respect
|
# ? Jul 14, 2017 05:47 |
|
Don't you think quoting yourself is a bit go-che?
|
# ? Jul 14, 2017 06:06 |
|
Absurd Alhazred posted:Don't you think quoting yourself is a bit go-che? i have the best quotes, everyone says so, and your posting is fake news
|
# ? Jul 14, 2017 06:32 |
|
Go is a good language for emoji-oriented programming
|
# ? Jul 14, 2017 07:35 |
|
Coffee Mugshot posted:Seems like a bit of overkill to me since `cp` doesn't fail if the destination and source cannot be closed, anyways... (you might be able unable to close because someone else has the file open and is writing to it, but `cp` would still be successful). What? Of course cp fails if the destination and source cannot be closed. Go look at the source code: it checks the return value of close() and reports an error if it failed. And what weird operating system are you using where someone else having an open handle to a file prevents you closing your handle? That certainly isn't the case on Windows or Unix.
|
# ? Jul 14, 2017 09:14 |
|
Sounds to me like Go needs macros.
|
# ? Jul 14, 2017 12:21 |
|
Every language needs macros.
|
# ? Jul 14, 2017 12:39 |
|
Go 2 considered harmful
|
# ? Jul 14, 2017 15:51 |
|
Beef posted:Every language needs macros. Be careful what you wish for. Every project in my shop has essentially built their own language on top of macros, creating a mountain of wtf in the process.
|
# ? Jul 14, 2017 16:20 |
|
Beef posted:Every language needs macros. Every programmer needs the restraint to not use macros.
|
# ? Jul 14, 2017 16:22 |
|
Bongo Bill posted:Go 2 considered harmful From Artem Yarulin n Twitter:
|
# ? Jul 14, 2017 16:45 |
|
Bongo Bill posted:Go 2 considered harmful I was gonna say 'I think you mean "Go, too, considered harmful"' but they really are planning a 2.0 already aren't they? Well I'm sure it'll turn out to be boo_radley posted:From Artem Yarulin n Twitter:
|
# ? Jul 14, 2017 16:55 |
|
Wrong, companies are locking themselves so hard into go apps that its value will be beyond question, much the same way that it is verboten to denounce Ronald Reagan in a public forum
|
# ? Jul 14, 2017 17:58 |
|
Gazpacho posted:companies are locking themselves so hard into go apps "Companies" plural?
|
# ? Jul 14, 2017 19:01 |
|
Gazpacho posted:Wrong, companies are locking themselves so hard into go apps that its value will be beyond question, much the same way that it is verboten to denounce Ronald Reagan in a public forum Is that based on docker being written in go?
|
# ? Jul 14, 2017 19:13 |
|
idiotmeat posted:Is that based on docker being written in go?
|
# ? Jul 14, 2017 20:08 |
|
JawnV6 posted:"Companies" plural? Alphabet contains multitudes
|
# ? Jul 14, 2017 20:39 |
|
taqueso posted:and Definitely. Nothing more dangerous than a programmer discovering macros for the first time. But having it around helps avoid horrors like the "format a string + exerc/eval" crap. Or being stuck copy pasting boiler plate because your language designer things generics are evil or whatever. Or writing a source file, syscalling gcc and dlopening the result. Or having to deal with an anemic preprocessor. Or templating your code with unicode glyphs and code generating. Beef fucked around with this message at 12:07 on Jul 15, 2017 |
# ? Jul 15, 2017 11:49 |
|
|
# ? Jun 5, 2024 20:10 |
|
Coffee Mugshot posted:I'm not sure how Go especially lets you ignore errors. Errors are values and Go doesn't force you to do anything with them in particular, it just stuffs them in your face at all times to remind you. In other languages, you write similar code like `file.open` and without putting try-catch around it, you are able to ignore the errors effectively. Unless you're talking about a run-time error catching it for you, such as a segmentation fault; Go will panic appropriately on those defer statements as well. Implicitly letting programmers accidentally forget to handle errors should be blamed on the language and not the programmers.
|
# ? Jul 15, 2017 14:40 |