D'après ce que j'ai compris c'est plutôt résevé pour le serveur d'application Easerver. Donc cette clause est inutile, si on n'utilise pas EaServer. En tous cas moi je ne l'ai jamais utilisé bien que j'ai un systéme de gestion des erreurs asez sophistiqué.

Dernière modification par Dadone (18-01-2008 15:06:11)

thezerg a écrit:

Justement à propos de la gestion des erreurs,peut on créer une exception et déclencher une erreur lorsqu'on le souhaite ?
je ne sais pas si je suis très clair...

Oui c'est comme en Java.
La seule contrainte est que tu dois compiler en pbd (ie : pas de dll)

Donc, quand le champs throws est présent, la fonction est susceptible de déclencher une exception.

Pour créer une exception :
New->Standard class->Exception

précision :

public function integer of_divide (double a, double b) throws nvo_exception;
nvo_exception ex

if b=0 Then
  ex = create nvo_exception
  ex.setMessage("Erreur de division par zero")
  throw ex
END IF

return a / b
end function

thezerg a écrit:

Merci mais compiler en pdb ca m'arrange pas

Est tu bien sûr que l'application soit plus rapide compilée en dll ?
Moi pas

shahin a écrit:

Est tu bien sûr que l'application soit plus rapide compilée en dll ?
Moi pas

Non je suis pas sur.. mais bon c'est comme ca chez le client.. 

[EDIT]

Je dis n'importe quoi c'est en PBD ..

thezerg a écrit:

A quoi sert ce champs dans une fonction d'un uo par exemple ?
Il sert à gérer les exceptions? Si oui comment?

Merci

Je voudrais profiter de la question originale pour clarifier un truc qui, je l'ai deja beaucoup constaté, echappe un peu a pas mal de developpeur PB n'utilisant pas les exceptions tout les jours...
Le fameux "champs throws" est la uniquement pour dire que ce script est susceptible de lancer une Exception non catchée dans ce script. Par un "throw xxx" avec xxx une instance d'exception.
Si on ne rempli pas bien ce champs, on a une erreur lors de la validation du code par PB, a qui ca ne plait pas.

Ca, c'est comme dans pas mal de langages gerant les exceptions.

Toutefois, il existe aussi une 2eme voie, celle des runtimeerror, pas assez souvent utilisee a mon sens. Elle a qques avantages:
- un throw runtimeerror ne necessite pas de remplir le champs throws du script ou on l'ecrit.
- une runtimeerror lancee se popule automatiquement avec le nom du script, la ligne,... ou l'erreur s'est produite.
- dans un script appelant le script susceptible de lancer une exception, le compilateur oblige soit a faire un try...catch autours de cet appel, soit definir le champs throws de l'appelant a son tour, comme susceptible de lancer une exception non catchée. Ce qui doit se finir a force d'appels par au moins un try...catch. Pas avec les runtimeerror...!
- sachant cela, il est evident que c'est une feature peut-etre exclusive de PB (je connais pas d'autre exemple de langage supportant des exception non catchees)

Et donc, ce sont 2 branches d'objets throwable, qu'on peut heriteer, et qu'on ne devrait pas negliger d'utiliser a profusion...
Voila, fini...

Cortex

Bah tu démérite pas ton nom quand même

000 pépites pour ces explications claires et très instructives

Dernière modification par Nephtis (28-03-2008 09:50:31)