on dira ce qu'on veut, moi quand je croise
dans du code, je me dis que même si ça a été facile à écrire (auto-complétion-power), ça reste lourd, c'est moche et ça encombre l'esprit de celui qui raisonne à propos du code. Et encore, il aura fallu importerLogger.getLogger(DimLocalHandler.class.getName()).log(Level.INFO,
"Further improvement possible.");
java.util.logging.Level, pour pouvoir "raccourcir" en Level.INFO, j'imagineOn a pas droit à
@INFO("Further improvement possible") ?
- + 
Vote for your favourite post
3 comments:
Pour simplifier un peu, tu peux ajouter un champ "final Logger log = Logger.getLogger(getClass());" à ta classe ver le logger, il ne restera plus qu'a écrire dans ton code :
logger.log(Level.INFO,
"Further improvement possible.");
tu peux aussi rendre ton logger static mais c'est controversé : http://forums.sun.com/thread.jspa?threadID=5269260
les choses du style @QuelQueChose("truc") sont des annotations. Elle n'ont pas de sens au seins du corps d'une méthode. A ma connaissance les annotations ne s'applique que sur les classes, champs et méthodes.
Je dois être trop habitué à rajouter des #define WARN(x, args...) klog(MODULE_NAME, LOG_WARNING, x, ##args)
En c++, j'ai fini par ajouter une classe top-level "iReport" de sorte que n'importe qui peut faire entrer les méthodes statiques "action" "report" "step" et "diagnose" dans son namespace à l'aide d'un simple " : public iReport"
Evidemment, C++ = sur DS = pas de multithreading :P
Post a Comment