Improve error reporting when loading the Docker configuration file

[0xced]

What does this PR do?

This pull request improves error handling while reading the Docker context configuration file. It throws a new DockerConfigurationException instead of silently failing.

Also, since GetCurrentEndpoint() can't return null anymore there's no need to try the default GetSocketPathFromHomeDesktopDir() and GetSocketPathFromHomeRunDir() socket paths.

Why is it important?

Silently returning null instead of throwing proper exceptions makes it harder to diagnose issues.

Related issues

• Relates feat: Get Docker endpoint from Docker context #1235

How to test this PR

The DockerConfigTests were updated and a new ThrowsWhenDockerConfigEndpointNotFound test was added.

[netlify]

✅ Deploy Preview for testcontainers-dotnet ready!

Name	Link
🔨 Latest commit	69fff92
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-dotnet/deploys/68149d84bae16500084fd1d7
😎 Deploy Preview	https://deploy-preview-1263--testcontainers-dotnet.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[HofmeisterAn]

I'm trying to explain my concerns. Maybe this is hypothetical, but let's assume:

• The ~/.docker/config.json file exists.
• The file contains a currentContext node.
• The meta directory or file does not exist, or the currentContext cannot be found.
• The user runs a remote container runtime, e.g. configured with WithDockerEndpoint(Uri).

With this implementation, an exception will be thrown when creating the list of Docker endpoints to check for availability.

System.TypeInitializationException
The type initializer for 'DotNet.Testcontainers.Configurations.TestcontainersSettings' threw an exception.

DotNet.Testcontainers.Builders.DockerConfigurationException
The Docker context '...' does not exist

System.IO.DirectoryNotFoundException
Could not find a part of the path '...'.

This prevents users from overriding the builder configuration using the API mentioned above. That said, I don't think WithDockerEndpoint(Uri) is the real issue here. If a user falls back to this API by default, something else is probably wrong.

My main concern is that this exception could also happen in other configurations. I believe this was one of the reasons we didn't throw exceptions in the initial implementation of Docker context support (IIRC, we removed it on purpose). Until now, we've been failing silently allowing another provider to find an available Docker endpoint.

The DockerConfigTests were updated and a new ThrowsWhenDockerConfigEndpointNotFound test was added.

I definitely agree with you on this. It bothers me too. I don't have a strong opinion on this PR. I was considering adding more logging to show which provider is processed and chosen (and which ones aren't). But if you don't see any issues with throwing an exception, we can go ahead and merge it. LMKWYT.

[0xced]

I agree that it's a bit unfortunate to throw if a valid endpoint is configured through WithDockerEndpoint(Uri). On the other hand, not throwing in this case makes it really hard to diagnose a broken Docker Desktop configuration.

Also, this case should really be exceptional and I think it warrants an exception that must be addressed by actually fixing the Docker Desktop configuration.

There's also this important change in the DockerDesktopEndpointAuthenticationProvider:

diff --git b/src/Testcontainers/Builders/DockerDesktopEndpointAuthenticationProvider.cs a/src/Testcontainers/Builders/DockerDesktopEndpointAuthenticationProvider.cs
index f2363f89..e1352585 100644
--- b/src/Testcontainers/Builders/DockerDesktopEndpointAuthenticationProvider.cs
+++ a/src/Testcontainers/Builders/DockerDesktopEndpointAuthenticationProvider.cs
@@ -15,7 +15,7 @@ namespace DotNet.Testcontainers.Builders
     /// Initializes a new instance of the <see cref="DockerDesktopEndpointAuthenticationProvider" /> class.
     /// </summary>
     public DockerDesktopEndpointAuthenticationProvider()
-      : base(DockerConfig.Instance.GetCurrentEndpoint()?.AbsolutePath, GetSocketPathFromHomeDesktopDir(), GetSocketPathFromHomeRunDir())
+      : base(DockerConfig.Instance.GetCurrentEndpoint())
     {
     }

It means that Testcontainers won't blindly try to connect to potentially valid sockets (from home desktop or home run directories). I've experienced issues doing so in the past where the socket was existing and but connecting to the socket would just stall because the engine was not running. It was very hard to diagnose!