BucketExistsAsync returns true even if it does not exist

[RoyalScribblz]

The logic for BucketExistsAsync is incorrect. All it determines is that the response Exception isn't a BucketNotFoundException. This means if you have another exception such as HttpRequestException, it responds that the bucket exists true even when it might not.

minio-dotnet/Minio/ApiEndpoints/BucketOperations.cs

Lines 83 to 85 in 2e46392

	return response is not null &&
	(response.Exception is null ||
	response.Exception.GetType() != typeof(BucketNotFoundException));

I was getting a "The SSL connection could not be established, see inner exception." and never knew until I stepped into the lib code.

[albracko]

This is not the only method that has wrong exception handling. I just lost few hours trying to figure out why BucketExistsAsync returns true, yet method ListBucketsAsync returns an object that was created with default constructor.

In my case i had wrong endpoint, but NO info about this in logs or any exception...which was harder to find out because i was testing on Gitlab CI....so had only logs available

I looked up your code, and the implementation of ExecuteTaskCoreAsync is not in-line with error handling in your API methods. All errors are basically being swallowed, leaving developers searching for a true cause why the API is not working.

[RoyalScribblz]

Yes @albracko I also experienced this with putting and getting objects, I spent a while trying to figure out why I get "" response back from getting object but turns out whole time it was never even putting anything in there in the first place as there was no connection but it swallowed exception.

[rekarpcpro]

I think exception handling needs a review.

my code:

bool exists = await minioClient.BucketExistsAsync(new BucketExistsArgs().WithBucket(bucketName));

I will get true even if the minio container be down and not be accessible by any mean 🙄