Main Site Documentation

RN171 library throw exception handling


#1

Using the latest version of the Wifly module, I ran into this problem.
In case I deliberately force an exception via a wrong argument value of method wifi_RN171.EnableDhcp();
Running the code the exception is not handled as I expected, i.e. the catch clause code is not executed.
Using the debugger the throw is reported by the debugger. Possibly a matter of :wall:

            
wifi_RN171 = new GTM.GHIElectronics.WiFiRN171(1);
try 
{
    wifi_RN171.EnableDhcp("", "255.255.255.000", "192.168.0.1");
}
catch (ErrorReceivedException ex )             {
     debug.print("Exception");
}

#2

@ freeck - I do not have the code for the library in front of me, but based on the code snippet you provided there is no reason to believe that an ArgumentNullException should be thrown, none of the arguments you are passing are null.


#3

@ freeck - Looking at the code quickly, I don’t see where that exception would come from. Do you have a stack trace?


#4

Snippet that generates the exception:

private void OnSerialLineReceived(string line)
 {
 if (this.commandModeResponse.IndexOf("ERR") >= 0)
 {
     this.commandResponseComplete.Set();
     throw new ErrorReceivedException(line);
  }
  }

#5

@ freeck - Right, “” should not be interpreted as null. It’s string.Empty. A stack trace would show us where the exception came from.


#6

sorry I put you on the wrong track, the exception came from another source.
I changed the example above with a different exception, and still I do not reach the catch clause…
A standard exception like a “devidebyzero” behaves as expected…


#7

@ freeck - In your edited example, there is no way for that exception to be caught. It occurs inside an event handler.


#8

OK! But what then is the function of the exceptions in the wifly-library? How should I handle these exceptions (perhaps a beginners question) ? :-[


#9

@ freeck - The driver should not be throwing an exception in event handlers. It should raise an event instead. Sadly, since the module is discontinued, it is unlikely we will be able to rework the driver that much.

You can always edit the driver source yourself for your project at https://bitbucket.org/ghi_elect/gadgeteer/src/58ba2e47a2c51c34c3a3846fff4325ef6e6816c4/Modules/GHIElectronics/WiFiRN171/WiFiRN171_43/WiFiRN171_43.cs?at=master

You can also look into why the module is returning an error and try to avoid it.


#10

Well, I intentionally used a wrong argument to force and test the exception mechanism…
Using exceptions in rare cases is very elegant! So i will try to modify the code to generate exceptions that can be caught on the application level.


#11

Hi freeck,
I spent some time modifying the GHI RN171 driver and I have some functions working quite well:

https://www.ghielectronics.com/community/codeshare/entry/927

What are you going to do with the RN171? Perhaps you can use my driver modification.
Which mainboard are you using?
Cheers
Roland


#12

@ RoSchmi - I know you are… :smiley: I read al your posts concerning this module. I have got library 4.2 working. but when I looked at the latest version 4.3 it seemed the code was better than the previous versions. But unfortunately this seems to be not always the case. Still i would like to use the latest version as a starting point for further modifications. I am looking for a way to extend this library with new methods as separate extensions, and not develope and maintain a complete new modified wifly-library.
perhaps using partial classes is a way to do so, but I am a medior C# programmer , perhaps the are better ways to do so.
Has GHI some recommendations concerning this.
I am more that happy to start a new topic on this issue and see how to continue…

PS: i use the cerbuinobee mainboard