Poll: .NET Pop Quiz



  • If we try to call System.IO.File.GetLastWriteTime() but give it a path to a file which doesn't exist, then this function will:

    • Throw a System.IO.FileNotFoundException.
    • Return 12:00 midnight, January 1, 1601 A.D. (C.E.) Coordinated Universal Time (UTC), adjusted to local time.

    (Hint: it's the other one.)


  • sockdevs

    It should throw an exception… so I'm guessing it returns the DateTime instead :laughing:



  • Well that's dumb.



  • Taking this quite seriously, and bearing in mind I never touch this stuff. I would pick UnauthorizedAccessException



  • It used to throw IOException but between .NET 2 and .NET 3.5 it got removed.



  • I might be the WTF here, but then again I'm only implementing the spec I've been given, and I turn to the .NET system libraries to build a path from user-given segments.

    Console.WriteLine(Path.Combine("c:/", "subdir-1", "/subdir-2", "subdir-3"));
    [spoiler]/subdir-2\subdir-3[/spoiler]
    Who expected that!?



  • .NET framework throws an exception when you make a HttpWebRequest and get a 404 in return. (Not an exception occurrence by any stretch of the imagination.)

    So it's awesome that in this case when it should throw an exception, it doesn't.

    If it returned DateTime.MinValue that might make some kind of sense... maybe?



  • @loose said:

    Taking this quite seriously, and bearing in mind I never touch this stuff. I would pick UnauthorizedAccessException

    That's what should be thrown if you'd have insufficient permission to access the last write time on a file or insufficient permission to access the file in general. I'd expect a FileNotFoundException if the file really doesn't exist.

    Either way, MS chose to do some profoundly weird stuff here. I wonder why...


  • sockdevs

    Probably some weird FAT legacy shit or something

    Edit: ↓ Seems I was right, sort of



  • @blakeyrat said:

    If it returned DateTime.MinValue that might make some kind of sense... maybe?

    It's the lowest FILETIME in WinAPI. So the .NET code probably doesn't even know whether it gets passed a valid date or an error indication (and Jan 1 1601 is technically a valid date).

    As for the "why" - maybe it's somehow cheaper not to test for existence, I dunno.



  • Right; but .NET is cross-platform, which means non-WinAPI platforms have to go out of their way to generate that date. Which is fucking ridiculous.

    It's in System.IO, not Microsoft.X


  • sockdevs

    Do they though? Is it not one of those things that's left up to whatever API .NET sits on top of?



  • @RaceProUK said:

    Do they though?

    Yes.

    The documentation says it generates that date. It doesn't say it generates that date on Windows, or when using NTFS, or anything that allows any space for variation.

    Other OSes either have to artificially generate that date, or not be in compliance with the .NET specification.

    This is sloppy, sloppy work from Microsoft. Much worse than the "returning an exception for a 404" thing.


  • sockdevs

    Is the MSDN documentation a 1:1 match for the .NET specification though? I don't disagree it's sloppy, of course it is; I just don't buy the idea that the MSDN docs are an exact match for the .NET spec.



  • Jesus.

    Look, even if the spec says "returns some random-ass date, I dunno, why not", it's still sloppy work so please don't bother asking these stupid clarifying questions if they don't change the fucking point I'm trying to make.

    Turn your head around and look! There's a forest by all the trees!


  • sockdevs

    If only I said

    @RaceProUK said:

    I don't disagree it's sloppy

    And if only you read that instead of being a colossal bell-end



  • Oh no, I saw that, but it's kind of negated by the fact that you still typed the fucking question. If you agree with my point, then why the fuck are you asking!? Christ.


  • sockdevs

    Thanks for proving, counter to your many claims, that it is impossible to have a basic conversation with you



  • It's certainly possible, but you have to refrain from typing really fucking stupid shit that pisses me off.

    Come on. You knew it was stupid when you hit enter. You hit enter anyway. What did you expect would happen? "Oh I'm going to type this really fucking stupid shit and post it and it'll be all sunshine and roses! Blakeyrat loves talking to stupid people! He'll love seeing a little blue 1 in his notifications!"



  • Try

    Path.IsPathRooted("/subdir-2")
    

    If it's true that means your dir is rooted, better hit it with a dban just to be safe.


  • sockdevs


  • Discourse touched me in a no-no place

    @nexekho said:

    Who expected that!?

    I would've expected that, as "" is the correct path separator, not "/", even though Windows recognizes it.



  • But whyyyyyyy would you ever break it like this? This must be a major regression for people that previously used that API.
    And that part of. Net i obviously not open sourced yet, so we're not able to check the implementation, or see the history.



  • @blakeyrat said:

    .NET framework throws an exception when you make a HttpWebRequest and get a 404 in return. (Not an exception occurrence by any stretch of the imagination.)

    It's a lose-lose situation. Either the library throws exceptions for "you requested something but the server doesn't have it" or we get problems like that android bitcoin miner thing.



  • Go gets it right.



  • Isn't the opposite true? Windows doesn't recognize it in some cases, but NTFS allows either '\' or '/' interchangeably?



  • @ben_lubar said:

    It's a lose-lose situation for languages without pattern matching and enumerated types

    GTFY


    Filed under: I agree with whatever @Gaska just said



  • How would that help? It's either going to crash your program or do something stupid if you don't handle it correctly.



  • Because you can't get the value without acknowledging that an error is possible.



  • Wait, you're saying that a function that returns an HTTP response has different return types for 404 and 200 that don't share something as simple as a "get the body of the response" method?



  • I didn't say that. I said that

    let result = match response {
      HttpResponse::Success(body) | HttpResponse::ClientError(body) => body,
      _ => return Err,
    }
    

    is less likely to happen than that bitcoin miner thing, or an unhandled exception.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    Isn't the opposite true? Windows doesn't recognize it in some cases, but NTFS allows either '' or '/' interchangeably?

    I dunno. If you care, you can look it up. The point was that "" is canonical, but "/" will work, so when you put things together, you can see both "/" and "" in a path.



  • But @nexekho's problem was that combining a path containing a path separator in one of the segments gives you something without the first few bits of the path.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    But @nexekho's problem was that combining a path containing a path separator in one of the segments gives you something without the first few bits of the path.

    Oh. Yeah, that's the defined behavior: If one of the subsequent paths is also an absolute path, the combine operation discards all previously combined paths and resets to that absolute path.

    Surprise!

    You can make an argument that that makes sense.



  • @ben_lubar said:

    But @nexekho's problem was that combining a path containing a path separatorrooted path in one of the segments gives you something without the first few bits of the path.anything before the root.

    Try to keep up.



  • I'm sorry, but \ isn't a path separator on Linux. That program will have similar output to the one I posted earlier if run on Windows.



  • equally incorrect?



  • Does C:\Windows\\System32 suddenly exist at the root of the drive?



  • Not on linux it doesn't.



  • Okay, we're not talking about the same thing. Path.Combine is a stupid function. What you really want is filepath.Join.



  • /subdir-2 isn't a relative path, regardless of what the person who chose its name believes. Treating it as one is not a good idea, regardless of what the person who wrote filepath.Join believes.



  • What kind of "join path elements" function takes absolute paths as arguments?



  • Both kinds, apparently.



  • @Ragnax said:

    I wonder why...

    I'm guessing, but there's at least one convenient use case for this: overwriting files with more recent versions only. If nonexistent files seem to have timestamps as far in the past as possible, all you need to do is compare the timestamp on source and destination files and do the overwrite if the source timestamp is later.



  • Here I was thinking that a "join path elements" function would take something called a "path element" as an argument.



  • func Join(elem ...string) string
    


  • Does elem mean "absolute path" in your native tongue?



  • Wait, elem is the parameter type they're? Go is even more fucked than I imagined.



  • What if you want to find the oldest file in a directory by brute forcing it? You'll always get a nonexistent file.



  • No, string is the type. Generally, the name of the argument to a function tells you what you should put in there. For example,

    func Split(s, sep string) []string
    

    You give it a string and a separator.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.