3 replies to this topic

[Fabien Royer]

Hi Chris,

After working with the StorageDevice class for a while now, I wanted to share some thoughts with you:

• The class is currently defined as "public static class StorageDevice".

As a 'resource' type of class, it would be beneficial to allow the following instead:

• Allow instantiation on the heap
• Have StorageDevice implement the IDisposable interface

These changes would allow for a using() {...} clause on the StorageDevice class which would guarantee that the resources can get cleaned up properly when an exception occurs.

For instance, today when the call to StorageDevice.MountSD() fails (at least with 4.1.1 Beta 1), the underlying SPI resources don't appear to be fully cleaned up, leaving SPI in a state that's unusable. Calling StorageDevice.Unmount() does not help to clean things up in this case since the StorageDevice.MountSD() never actually allocated the resources.

What do you think?

Cheers,
-Fabien.

[Chris Walker]

Hi Fabien, If StorageDevice.MountSD() fails, it should clean up after itself. If it's not doing that, we should fix that The StorageDevice class is designed to provide static public methods for manipulation of storage devices...but we could certainly look at making it an instantiated class instead. My first thought is that would just make things more complicated for users and require more lines of code...but I'm open to it. Is there a good corollary to how this is done in the desktop .NET Framework? Chris

[Fabien Royer]

If StorageDevice.MountSD() fails, it should clean up after itself. If it's not doing that, we should fix that

Definitely

Is there a good corollary to how this is done in the desktop .NET Framework?

The examples abound: from Sql connections, to files or device handles, to sockets, to web requests, to fonts, to bitmaps... Basically, anything that's a resource or that has a 'handle' to underlying system resources benefits from the using statement.


For example: http://msdn.microsof...y/yh598w02.aspx

A quick Google search reveals many other examples.

I hope this helps make the case for using

[AlfredBr]

I too would prefer if StorageDevice were a regular class and not a static class. IMO, static classes are great for things like "Math.Xxx()" which do not hold state or have a lifetime. Also, it would allow for more natural subclassing, if it became necessary (minor).