24
Vote

EWR dependency

description

In current version, when stubbing out EWR, the system will always raise a "not implemented" exception on system power up coming from Microsoft.SPOT.IO.dll. While the system continue running safely after, seeing this exception is disliked by users and we always receive the same question "why this exception?"
 
Removing EWR dependency out of the internal libs will be ideal and if using EWR is a must then at least we need a way so there is no exception showing on power up.
 
An example http://www.tinyclr.com/forum/topic?id=7547
 
Gus - GHI Electronics

comments

JanKucera wrote Jul 11, 2012 at 7:41 AM

Gus and others: it is a normal thing that the debug output provides you information about catched exceptions that occur in the code, and developers should be familiar with this important feature. It happens in other projects too, not only in the .NET Micro Framework ones.

Removing the EWR dependency to overcome this is not an option. There are two ways to make your users happy: First, to fail the EWR write operation silently, that is, to return null data on recovery. By the nature of EWR, the code needs to count with this situation anyway. This, however, would be not only a breaking change to code that fallbacks to different mechanisms if it finds out that the EWR feature is not available, but it would make this scenario impossible. The other option is to make the EWR capability discoverable at runtime, and introduce checks of it in the BCL. That increases footprint, which is, especially on the devices where EWR is not available, usually an important measure. I am not sure I am fully supporting it just to suppress a message in a debug output, moreover appearing during debugging only...

gus_ghielec wrote Jul 11, 2012 at 5:37 PM

Hello Jan and thanks for the input.

Those small-memory devices already include EWR stubs so it is not too difficult for the core to detect if EWR is there with no much added to footprint. I agree it is a terrible idea to stop exceptions, which they are an essential part of any system. What I am saying is that if NETMF core libs shouldn't be using EWR as this is an optional part of NETMF. Also, if EWR was to be used then the code that uses it should detect it and use if available without raising exceptions.

I think that if EWR is optional then it has to be truly optional, no exceptions no impact; otherwise, take the stubs out and make it a required piece.

Some of the users that complained about this are a long time users of NETMF, not beginners. When they receive a device and they power it up the first time, seeing an exception is scary. They are not sure if they did something wrong or not. Imagine you just received a device and you are just loading your first app. How would you react to seeing an exception? Wouldn't you contact the supplier to check if this is normal or not? Now multiply this by few hundreds or thousands.

It is a small fix in NETMF that would make the the user experience (especially NETMF newcomers) much better.

Gus