BluetoothSocket.InputStream should throw a System.IO.IOException

[kwintAl]

BluetoothSocket.InputStream is a Stream and Stream.Read should throw a System.IO.IOException

Steps to Reproduce

1. Create SPP RFCOMM Connection

_adapter = BluetoothAdapter.DefaultAdapter;
// ...
var device = _adapter.GetRemoteDevice(address);
var socket = device.CreateRfcommSocketToServiceRecord(UUID.FromString("00001101-0000-1000-8000-00805F9B34FB"));
await socket.ConnectAsync();
var stream = socket.InputStream;

2. start read operation

try {
     var buffer = new byte[128];
     var read = stream.Read(buffer, 0, buffer.Length);
    // ...
}
catch(IOException e) {
    throw;
}
catch (Exception e)
{
    // Java.IO.IOException...
    throw;
}

3. turn remote device off and wait few seconds

Expected Behavior

System.IO.IOException

Actual Behavior

Java.IO.IOException

Version Information

Log File

[gugavaro]

@grendello have we deal with similar issue in the past?

[grendello]

@gugavaro yes, but for our own code, not the platform code.

@kwintAl In this case I don't believe we should wrap the native exception in a .NET one. We merely provide a thin bridge between the .NET land and the Java land and the type is inherently Java/Android. Therefore it should throw exceptions documented in Android docs (in this case here) to stay as close as possible to the platform. Whenever one uses a type from the Android* namespaces, it should be expected that such classes will throw Java exceptions in some situations, not the .NET BCL ones. Changing the behavior here would require to change the behavior everywhere else for consistency - and that's not a small task, not to mention breaking backward compatibility.

[kwintAl]

We merely provide a thin bridge between the .NET land and the Java land and the type is > inherently Java/Android

@grendello the return type ist not Java.IO.InputStream like in native Android/Java it's a System.IO.Stream see links above.

[get: Android.Runtime.Register("getInputStream", "()Ljava/io/InputStream;", "GetGetInputStreamHandler")]
public System.IO.Stream InputStream { get; }

And if I get a System.IO.Stream, how should I figure out this is a Java.IO.InputStream and then catch a Java Exception?

System.IO.Stream is available in .NETStandard and if Java.IO.IOException will be thrown in the platform independent code, I have no chance to catch it, only with catch(Exception). And this is not the best choice because of other exceptions like ArgumentException etc. I don't want to catch in this case(bad practice)

From my point of view there are two possible fixes:

• return Java.IO.InputStream
• throw System.IO.IOException

[grendello]

@kwintAl System.IO.Stream merely wraps the underlying Java stream. It was a design choice made years ago (in the days of MonoAndroid), and not a good one. We can't undo it now because it could break an unknown number of applications without any warning or error until those applications run, merely after recompiling them with Xamarin.Android having the change you proposed. We would prefer to throw .NET BCL exceptions, but alas - we can't really make the change. You can assume that if you're dealing with an Android.* type then the exceptions thrown will be the Java ones. Regarding returning Java.IO.InputStream - it's an API and ABI breaking change as Java.IO.InputStream does not derive from System.IO.Stream, so unfortunately the same remarks as above apply here.

Yes, we are aware that handling Java exceptions in PCL or NetStandard assemblies is problematic, but we see no good solution for this right now. We have a few ideas how to solve this, but they are still being discussed and not even ready for proof-of-concept code. You can still catch Exception and then do ex.GetType().ToString() and check if it's one of the Java.* exceptions. Yes, I realize this is not ideal and slow, but it's about the only option right now to implement in PCL or NetStandard code.

[kwintAl]

We can't undo it now because it could break an unknown number of applications without any warning or error until those applications run, merely after recompiling them with Xamarin.Android having the change you proposed.

Currently you're breaking an unknown number of new applications, like my one.

Why not to do it on the next Major Release? Major Release means breaking changes, so someone updating to the next major should know the potential risk.

I do not really understand why this bug should not be fixed.

[jonpryor]

I do not really understand why this bug should not be fixed.

Mistakes were made, largely by me.

The fundamental problem was that in the beginning, we decided to bind java.io.InputStream and java.io.OutputStream as System.IO.Stream. This was a mistake. We can't easily fix this mistake without breaking API compatibility, which we can't really do.

We're stuck between a rock and a hard place, between backward compatibility and ecosystem compatibility.

Consider this GitHub search for catch (Java.IO.IOException in C# source code. There are at least 511 matches for that construct, some which will break with such a change, e.g.

• https://github.com/kpalok/Digifab/blob/master/FeederApp/BluetoothFeedService.cs#L210-L220
• https://github.com/AlejandroRuiz/Mono/blob/9fc7682cd82190b20e608198563c61ff3489544e/Tablet/Tablet/MainActivity.cs#L112

There are an unknowable number of existing, shipping apps that this change would break.

There are an unknowable number of future apps that not making this change will break.

Given the unknowns, we feel it is currently wiser to not change semantics here.

That said, a potentially "silly" workaround does come to mind: we might be able to employ the linker to "fixup" all catch blocks which catch System.IO.IOException and update them to also catch Java.IO.IOException, if Java.IO.IOException is not already handled. This would allow existing apps and new apps to work "as expected", but I don't know how difficult it would be to do this, or what other havoc such a change may cause.