[font=Arial,]Important: Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors (such as a file not being accessible)[/font]
Important: In many environments, use of exceptionsisfairly commonplace. For example, you mightthrow
an exception to signalthat a routine could not execute normally"such as when a file is missing or data
Apple déconseille l'utilisation des exceptions en objective C, donc à éviter.
Ce n'est pas tout à fait vrai. Apple recommande de réserver l'usage des exceptions aux erreurs de programmation (un développeur utilise mal une classe, par exemple).
Une fois livrée à un utilisateur, le code ne devrait plus lever d'exceptions.
On s'en fout de l'avis d'Apple /smile.png' class='bbc_emoticon' alt=':)' />
D'autant qu'il en change comme d' iPhone !
L'important c'est d'être cohérent, soit on gère les erreurs par exceptions, soit par retour de méthodes, mais pas les deux à la fois.
Ce qui était le cas au début de Cocoa, par ex avec NSImage dont les méthodes initWith... pouvaient retourner nil mais aussi lever une exception ! Ce n'est plus le cas depuis les OSX récents (10.6 ?)
Apple a donc choisi finalement de gérer les erreurs courantes par retour de méthodes comme par ex:
En conclusion: tu peux suivre les recommandations d'Apple, mais c'est pas le plus important, l'important c'est de faire une interface de programmation cohérente pour l'ensemble de tes classes.
Non, on ne s'en fout pas, surtout si on utilise ARC, car ARC + Exceptions = Leaks...
M'en fout, je n'utilise pas ARC /kiss.gif' class='bbc_emoticon' alt=':-*' />
La solution, c'est de limiter l'utilisation des exceptions à la gestion interne à une classe. Ces exceptions ne doivent pas remonter au niveau du programme appelant.
For example, a parsing library might use exceptions internally to indicate problems and enable a quick exit from a parsing state that could be deeply recursive; however, you should take care to catch such exceptions at the top level of the library and translate them into an appropriate return code or state.
Il se trouve que c'est exactement ce que fait dans mon parser JSON cité plus haut:
Réponses
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Exceptions/Tasks/RaisingExceptions.html
Apple déconseille l'utilisation des exceptions en objective C, donc à éviter.
Ah bon
Important: In many environments, use of exceptionsisfairly commonplace. For example, you mightthrow
an exception to signalthat a routine could not execute normally"such as when a file is missing or data
couldnotbeparsedcorrectly.Exceptionsareresource-intensiveinObjective-C.Youshouldnotuseexceptions
for general flow-control, orsimply to signify errors. Instead you should use the return value of a method or
functiontoindicatethatanerrorhasoccurred,andprovideinformationabouttheprobleminanerrorobject.
For more information,see ErrorHandling ProgrammingGuide For Cocoa
Ce n'est pas tout à fait vrai. Apple recommande de réserver l'usage des exceptions aux erreurs de programmation (un développeur utilise mal une classe, par exemple).
Une fois livrée à un utilisateur, le code ne devrait plus lever d'exceptions.
D'autant qu'il en change comme d' iPhone !
L'important c'est d'être cohérent, soit on gère les erreurs par exceptions, soit par retour de méthodes, mais pas les deux à la fois.
Ce qui était le cas au début de Cocoa, par ex avec NSImage dont les méthodes initWith... pouvaient retourner nil mais aussi lever une exception ! Ce n'est plus le cas depuis les OSX récents (10.6 ?)
Apple a donc choisi finalement de gérer les erreurs courantes par retour de méthodes comme par ex:
+ (id)fileHandleForReadingFromURL:(NSURL *)url error:(NSError **)error
Et c'est plutôt une bonne idée.
Mais l'important pour ses propres développement c'est de définir un paradigme de programmation pour la gestion d'erreurs et de s'y tenir.
Néanmoins il reste des situations où les exceptions sont inévitables, comme les erreurs de syntaxe dans les parsers, ici un parser JSON:
Perso j'ai pas trop de cas d'utilisations des exceptions en ObjC, car pour ce genre de choses j'utilise le C++:
C'est vraiment l'utilisation basique des exceptions, tellement basique que ça ressemble furieusement à l'utilisation des longjmp en C:
En conclusion: tu peux suivre les recommandations d'Apple, mais c'est pas le plus important, l'important c'est de faire une interface de programmation cohérente pour l'ensemble de tes classes.
Non, on ne s'en fout pas, surtout si on utilise ARC, car ARC + Exceptions = Leaks...
http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions
M'en fout, je n'utilise pas ARC
La solution, c'est de limiter l'utilisation des exceptions à la gestion interne à une classe. Ces exceptions ne doivent pas remonter au niveau du programme appelant.
Il se trouve que c'est exactement ce que fait dans mon parser JSON cité plus haut:
C'est deux méthodes retournent nil en cas d'erreurs.