Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Wed Nov 22, 2017 5:51 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Thu Sep 03, 2009 12:33 pm 
Offline

Joined: Fri Aug 28, 2009 10:26 am
Posts: 4
I am using serial communications and occasionally I get some bad data.

Essentially I am expecting a numeric response from a device being polled. I use the following line to convert the string data to an integer value

val(mynumber, serialoutstring)

Occasionally I get string data containing non numeric data like
serialstring="~A"

at which point I get the following error:
"Exception 136: Val: Illegal value given by string (severity: 5) (SerialComm line 7)"

Is there an easy work-around to prevent non integer data (negative and positive values allowed)? Or do I need to check character in the string for the proper ascii value?


Top
 Profile  
 
PostPosted: Thu Sep 03, 2009 12:38 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Code:
check error
    val(mynumber, serialoutstring)
    'Perform the rest of your cod that assumes a good numeric value here
on error
    _ClearException()
    'Perform error handling here
enderr

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Fri Feb 25, 2011 2:19 pm 
Offline

Joined: Thu Dec 03, 2009 9:18 am
Posts: 15
Thanks, this was helpful to me as well. BTW - I could not find anything in the documentation pointing me to _ClearException(), so I would not have been able to clean this up without this forum to point me there.


Top
 Profile  
 
PostPosted: Fri Feb 25, 2011 2:47 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Exception handling is covered in section 2.15 of the Programmer's Reference and 10.4 of Qlarity Foundry. I have added some notes that we could use some more example code in each of those sections.

The reason that those sections don't explicitly call out _ClearException() is that _ClearException is not an API or built in function, rather it is a little snippet of Qlarity code that originally looked like this
Code:
func _ClearException()
    dim errStr as string
    dim errTyp, errLev as unibyte
    GetException(errStr, errTyp, errLev)
endfunc


In other words it was simply a wrapper for the mandatory (and documented) call to GetException. The reason that _ClearException was useful is that in many/most exception situations you have a very good idea of what happened and so the extra code to declare the variables to receive the exception information was fairly tedious and not very useful.

With the addition of the "Extra Exception Tracking" option, the _ClearException code became slightly more sophisticated to deal with the fact that when that option is enabled, that multiple exceptions could be enqueued in situations where normally only a single exception is generated.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Fri Feb 25, 2011 3:42 pm 
Offline

Joined: Thu Dec 03, 2009 9:18 am
Posts: 15
Thanks. I think my confusion started with this language in Sec 2.15 in the Programmers Reference:
Quote:
If the "on error" block doesn't resolve the exception, it can call Rethrow() to allow a higher level "check error" to handle it.

Reading this, I assumed that if I didn't Rethrow(), then my 'on error' statement would have caught and handled/absorbed the exception, and it wouldn't propagate further, which apparently isn't the case.
My two cents, is it would be nice for the language in that section to explicitly mention how to cancel the exception.


Top
 Profile  
 
PostPosted: Fri Feb 25, 2011 4:06 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I agree that the wording is a bit confusing, especially the programmer's reference. This is compounded by the fact that the Programmer's reference doesn't clearly describe that there are two mechanisms at play here.

The first mechanism is a exception bubbling mechanism similar to that used in many modern programming languages (e.g. Java, C#, C++ and others) where when an exception is encountered, execution will jump to the nearest on error (catch) block. If no such block exists in the current stack frame it will "bubble" up the stack until one is found. If no check error block is found, then the current Qlarity message is then terminated (unlike some of the aforementioned languages, this is not fatal in Qlarity -- message processing will proceed to the next message, which would always be a MSG_ERROR in this case).

The second mechanism in play is unique to Qlarity. When an exception is generated it is placed on an exception stack. GetException() pops the first exception from the stack and returns it to you. Rethrow simply the most recenlty popped message back onto the stack and resumes starts check error "bubbling" again. Now if the processing of a Qlarity message ever completes and the exception stack is not empty, then a MSG_ERROR is generated. Most Qlarity applications include an ExceptionDisplay object which processes MSG_ERROR to generate the familiar green screen.

The big gotcha with the second mechanism that tends to throw people off is the fact that it is very easy to handle an exception (i.e. catch the "bubbling" effect) yet fail to pop the exception from the stack. This means that in code like this

Code:
dim didDivision as boolean
dim caughError as boolean
dim finishedErrorBlock as boolean
check error
    i = i / 0
    didDivision = true
on error
    caughtError = true
enderr
finishedErrorBlock = true


then after all processing is complete, didDivision will be false (because the exception occurred before the assignment). caughtError will be true -- because we did catch the exception. Also finishedErrorBlock will be true, because execution continued past the error block. However you would still get a "green screen" because all functions in the stack would complete and control would return to the firmware. The firmware would see that a divide by zero exception had been pushed but not popped and would generate a MSG_ERROR. Adding a call to GetException in the on error block would fix this. In most of the Qlarity code we write this would be indirectly via a call to _ClearException. However _ClearException came into being around the time of Qlarity 2, so documentation written earlier wouldn't mention it.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group