Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

curufinor: Apr 4, 2016; by Smythe

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

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 12:50

Jaded Burnout: Jul 10, 2004

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

Ranzear: Jul 25, 2013

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

Sedro: Dec 31, 2008

HFX posted:

Unless you have a subdomain of a subdomain. So modelenv.test.example.com will fail.

Same problem with certs, and getting all your subdomains can get expensive. There's an huge blog post about upgrading stackoverflow to https:

https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/#certificates

# ? Jul 13, 2017 19:24

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Eela6 posted:

What, seriously?

I, uh, I gotta go fix my codebase. gently caress go.

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

eth0.n: Jun 1, 2012

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

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Failing to close a file doesn't mean that the data isn't on disk.

# ? Jul 13, 2017 21:43

necrotic: Aug 2, 2005; I owe my brother big time for this!

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

b0lt: Apr 29, 2005

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.

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:

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

Eela6: May 25, 2007; Shredded Hen

necrotic posted:

you're using a remote file system thing like the article

bingo.

# ? Jul 13, 2017 21:50

vOv: Feb 8, 2014

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

necrotic: Aug 2, 2005; I owe my brother big time for this!

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

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

The idea is that you fsync and actually get told about any errors before you close.

# ? Jul 13, 2017 22:47

Hughlander: May 11, 2005

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

necrotic: Aug 2, 2005; I owe my brother big time for this!

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

Coffee Mugshot: Jun 26, 2010; by Lowtax

comedyblissoption posted:

https://hackernoon.com/correct-error-handling-is-hard-307ea72759c7

Silently letting you ignore errors as the default behavior is the hallmark of great language design.

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:

defer func() {
   if err := f.Close(); err != nil {
      panic(err)
   }
}

if you were truly desperate to match the default implementation of this in most languages or you could synchronously (or asychonously) wait for each close operation to finish and check the error like in the article. 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).

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

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

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:

    file = open(...)
    defer file.Close()

    value, err = foo()
    if err {
        log(err)
        return
    }
    file.Write(value)

    err = file.Sync()
    if err {
        log(err)
        return
    }
}

You don't care about errors from Close() if you're already exiting early due to a different error, and in the successful code path you've already called fsync() so it can't fail.

# ? Jul 13, 2017 23:18

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

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:

defer err := file.Close(); err != nil {
  whoops, close hosed up, handle it here
}

# ? Jul 13, 2017 23:22

Coffee Mugshot: Jun 26, 2010; by Lowtax

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:
code:
defer err := file.Close(); err != nil {
  whoops, close hosed up, handle it here
}

I'm not sure if this is different from

code:

defer func() {
    if err := file.Close(); err != nil {
        // Should never happen, do something serious or just log it maybe. 
    }
}()

or not. Another questionable way to do this is with named result parameters of course:

code:

func SomeInnocuousIOOperationThatProbablySilentlyFailsInANonMeaningfulWay() (err error) {
   // Opening files in a spooky way.
   defer func() {
        err = file.Close()
   }()
}

but I have a feeling this isn't the general solution we're looking for, despite what that article says

Coffee Mugshot fucked around with this message at 00:04 on Jul 14, 2017

# ? Jul 13, 2017 23:57

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Coffee Mugshot posted:

I'm not sure if this is different from

code:

defer func() {
    if err := file.Close(); err != nil {
        // Should never happen, do something serious or just log it maybe. 
    }
}()

or not.

It's not. Just prettier. And lord knows prettiness is not a high priority for the Go language developers.

# ? Jul 14, 2017 00:41

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

JavaScript code:

var foo = function() {
  return (
    // This comment makes Closure Compiler emit an empty function.
    false);
};

I spent a day on this. What the hell.

# ? Jul 14, 2017 01:11

JewKiller 3000: Nov 28, 2006; by Lowtax

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

Absurd Alhazred: Mar 27, 2010; by Athanatos

JewKiller 3000 posted:

Don't you think quoting yourself is a bit go-che?

# ? Jul 14, 2017 06:06

JewKiller 3000: Nov 28, 2006; by Lowtax

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

Coffee Mugshot: Jun 26, 2010; by Lowtax

Go is a good language for emoji-oriented programming

# ? Jul 14, 2017 07:35

Soricidus: Oct 21, 2010; freedom-hating statist shill

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

Pollyanna: Mar 5, 2005; Milk's on them.

Sounds to me like Go needs macros.

# ? Jul 14, 2017 12:21

Beef: Jul 26, 2004

Every language needs macros.

# ? Jul 14, 2017 12:39

Bongo Bill: Jan 17, 2012

Go 2 considered harmful

# ? Jul 14, 2017 15:51

idiotmeat: Apr 3, 2010

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

taqueso: Mar 8, 2004

Beef posted:

Every language needs macros.

and

Every programmer needs the restraint to not use macros.

# ? Jul 14, 2017 16:22

boo_radley: Dec 30, 2005; Politeness costs nothing

Bongo Bill posted:

Go 2 considered harmful

From Artem Yarulin n Twitter:

# ? Jul 14, 2017 16:45

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

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

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

JewKiller 3000 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

# ? Jul 14, 2017 17:58

JawnV6: Jul 4, 2004; So hot ...

Gazpacho posted:

companies are locking themselves so hard into go apps

"Companies" plural?

# ? Jul 14, 2017 19:01

idiotmeat: Apr 3, 2010

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

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

idiotmeat posted:

Is that based on docker being written in go?

Mainly, but not exclusively.

# ? Jul 14, 2017 20:08

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

JawnV6 posted:

"Companies" plural?

Alphabet contains multitudes

# ? Jul 14, 2017 20:39

Beef: Jul 26, 2004

taqueso posted:

and

Every programmer needs the restraint to not use macros.

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

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 12:50

comedyblissoption: Mar 15, 2006

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.

Some languages handle errors as values and also will warn you if you accidentally don't use a return value and handle the error.

Implicitly letting programmers accidentally forget to handle errors should be blamed on the language and not the programmers.

# ? Jul 15, 2017 14:40

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »