Yoctopuce Yocto-RangeFinder, User Manual, Page: 61 / 497

Common issues
For the HTTP callback API to work, the PHP option allow_url_fopen must be set. Some web site
hosts do not set it by default. The problem then manifests itself with the following error:
error: URL file-access is disabled in the server configuration
To set this option, you must create, in the repertory where the control PHP script is located, an .htaccess
file containing the following line:
php_flag "allow_url_fopen" "On"
Depending on the security policies of the host, it is sometimes impossible to authorize this option at
the root of the web site, or even to install PHP scripts receiving data from a POST HTTP. In this
case, place the PHP script in a subdirectory.
Limitations
This method that allows you to go through NAT filters cheaply has nevertheless a price.
Communications being initiated by the
VirtualHub at a more or less regular interval, reaction time to
an event is clearly longer than if the Yoctopuce modules were driven directly. You can configure the
reaction time in the specific window of the
VirtualHub , but it is at least of a few seconds in the best
case.
The HTTP callback Yocto-API mode is currently available in PHP, EcmaScript (Node.JS) and Java
only.
9.5. Error handling
When you implement a program which must interact with USB modules, you cannot disregard error
handling. Inevitably, there will be a time when a user will have unplugged the device, either before
running the software, or even while the software is running. The Yoctopuce library is designed to help
you support this kind of behavior, but your code must nevertheless be conceived to interpret in the
best possible way the errors indicated by the library.
The simplest way to work around the problem is the one used in the short examples provided in this
chapter: before accessing a module, check that it is online with the
isOnline
function, and then
hope that it will stay so during the fraction of a second necessary for the following code lines to run.
This method is not perfect, but it can be sufficient in some cases. You must however be aware that
you cannot completely exclude an error which would occur after the call to
isOnline
and which
could crash the software. The only way to prevent this is to implement one of the two error handling
techniques described below.
The method recommended by most programming languages for unpredictable error handling is the
use of exceptions. By default, it is the behavior of the Yoctopuce library. If an error happens while
you try to access a module, the library throws an exception. In this case, there are three possibilities:
• If your code catches the exception and handles it, everything goes well.
• If your program is running in debug mode, you can relatively easily determine where the
problem happened and view the explanatory message linked to the exception.
• Otherwise... the exception makes your program crash, bang!
As this latest situation is not the most desirable, the Yoctopuce library offers another possibility for
error handling, allowing you to create a robust program without needing to catch exceptions at every
line of code. You simply need to call the
YAPI.DisableExceptions()
function to commute the
library to a mode where exceptions for all the functions are systematically replaced by specific return
values, which can be tested by the caller when necessary. For each function, the name of each
return value in case of error is systematically documented in the library reference. The name always
follows the same logic: a
get_state()
method returns a
Y_STATE_INVALID
value, a
get_currentValue
method returns a
Y_CURRENTVALUE_INVALID
value, and so on. In any
case, the returned value is of the expected type and is not a null pointer which would risk crashing
9. Using Yocto-RangeFinder with PHP
www.yoctopuce.com 55