|
|
|
|
|
|
|
|
|
|
- Présentation
- Les assertions
- Mise en place
- Conseil
- Personnalisation de la fenêtre des assertions
WINDEV, WEBDEV et WINDEV Mobile disposent en standard de plusieurs outils et fonctionnalités pour aider à mettre au point et à optimiser les applications ou sites. Les principales fonctionnalités offertes en termes de mise au point sont les suivantes : Une assertion permet de vérifier une condition lors de l'exécution de l'application. Si la condition n'est pas vérifiée, une boîte d'information s'affiche avec le détail de la vérification. Le développeur a alors accès à la pile d'exécution, c'est-à -dire tous les appels qui ont abouti à ce résultat. Pour définir une assertion, il suffit d'utiliser la fonction dbgAssertion avec en paramètre : - la condition à vérifier,
- le message à afficher si jamais la condition n'est pas vérifiée.
// Variable CClient
clClient est un CClient
// Création du client
CréerClient(clClient)
// L'objet clClient doit avoir été instancié
dbgAssertion(clClient<>Null, "L'objet n'a pas été instancié") Par défaut, les assertions sont actives uniquement en mode test. Il est possible d'activer les assertions en déploiement : il suffit d'utiliser la fonction dbgActiveAssertion :
Attention : La condition utilisée dans l'assertion est exécutée par le WLangage uniquement lorsque les assertions sont actives. Le fonctionnement peut donc être différent en mode test et en mode exécutable. Il faut être particulièrement vigilant lors de l'utilisation de fonctions dans la condition fournie à la fonction dbgAssertion. En effet, si la fonction utilisée réalise une initialisation ou une connexion, cette opération ne sera pas réalisée dans l'application utilisée en mode "exécutable". En revanche, ce mode de fonctionnement permet de réaliser "plus de tests" sans ralentir l'application en exploitation. La mise au point des applications est ainsi plus rapide. Conseil Les assertions peuvent servir pour tester des cas "spécifiques" ou vérifier les "prérequis" d'une fonction. Il est ainsi possible de tester le cas qui ne devrait jamais arriver : - utilisation d'une chaîne vide alors qu'un nom logique est attendu,
- saisie d'un chemin vers un fichier inexistant, ...
Les assertions ne peuvent pas remplacer la gestion classique des erreurs. Mais mettre une assertion permet d'être prévenu et de retrouver pourquoi un problème est survenu grâce à la pile d'exécution. Les assertions permettent également de guider lors d'un développement à plusieurs développeurs : le code "appelant" ne doit pas provoquer d'assertions dans le code "appelé".
Documentation également disponible pour…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|