File lightbulb moment

I was always puzzled by something in the File class. It has getAbsolutePath() and getCanonicalPath() and they both do almost the same thing: return a fully qualified name of the file. One difference is that the "absolute" version doesn't simplify paths with ".." which makes the "canonical" version always looks tempting. But that version throws IOException, so you need a try block, which makes it a pain.

How could cleaning up a file path cause an IOException? Documentation says "construction of the canonical pathname may require filesystem queries" and I've never known what that could mean.

Today I passed a ridiculously long name to the "canonical" version and it said IOException: The parameter is incorrect. Shortening the name made it work. I think it's telling me "that file cannot possibly exist on this file system", which kind-of fits into the "filesystem queries" category mentioned in the docs.

Bird noticing

There was a blue tit on the bird feeder today. I watched it for a minute, but it was pretty small.

I have binoculars within arms reach, and through this whole lockdown, I haven't got them out to look at the birds. WTF? So I got them out of the case and the blue tit flew away before I lifted them to my eyes.

The rest of the afternoon was bird free except for fat pigeons. I don't want to fat-shame them, but where the other birds hop and flit, pigeons lumber around, even when they're flying.

Playing with ASCII art (er, UTF-8 art?)

 ─╖╓─╖
  ║╟─╨╖╓─╖╥─╖╓─╖╥─╖╓─╖
└─╜╙──╜╙─╨╙ ╜╙─╨╙ ╜╙─╨