• Este debate está vacío.
Viendo 2 entradas - de la 1 a la 2 (de un total de 2)
  • Autor
    Entradas
  • #31219
    Javier Ader
    Participante

    Bueno lo más probable es que los desarrolladores ya los conozcan, pero por las dudas los comento. Cargue el proyecto en eclipse, y rápidamente aparecen los warnings de uso de tipos “raws”; es bastante aceptable que estén ya que hay código de muchos años, cuando no existía la genericidad en Java (en realidad he vista mas de un proyecto de java exitosos que tiran esos warnings) así que opte porque no me los mostrase en las propiedades del proyecto (Properties -> Java Compiler-> Annotation Processing -> Errors/Warnings ,Enable project specif settings , Generic Types , Usage of a raw types -> Ignore). Supuse que iban a desaparecer todos, pero aún quedaron 100. El primero que veo esta libertya/FreeQueryBuilder/nickyb/fqb/nickyb/fqb/DesktopLoader.java, aparece algo como

    Code:
    try
    {…
    }fynally{
    return primary;
    }

    que me dejo perplejo jajaj que dilema conceptual! se propaga la excepción o se retorna del método como si nada hubiese pasado?? La verdad que no se, esta para ejercicio de programación (me la juego a que retorna lo más bien, aunque esto violaría la definición de finally). Casi seguro que lo que deberia haber es un catch (Throwable i) que no haga nada, y después un retrun primary fuera del catch.
    Igual, lo anterior me da la sensación que es código de 3ro. Pero el segundo que vi, es un Null pointer access y eso tiene que ser un bug (o hay algo que no me doy cuenta). Esta en libertya/base/src/org/openXpertya/process/ImportInvoice.java, linea 401, metodo doIt.

    Code:
    // BP Location

    MBPartnerLocation bpl = null;
    MBPartnerLocation[] bpls = bp.getLocations( true );

    for( int i = 0;(bpl == null) && (i < bpls.length);i++ ) { if( imp.getC_BPartner_Location_ID() == bpls[ i ].getC_BPartner_Location_ID()) { bpl = bpls[ i ]; // Same Location ID } else if( imp.getC_Location_ID() == bpls[ i ].getC_Location_ID()) { bpl = bpls[ i ]; // Same Location Info } else if( imp.getC_Location_ID() == 0 ) { MLocation loc = bpl.getLocation( false ); <--- ESTO siempre es una acceso a null via bpl

    Después hay una seguidillia de cerca de 10 Null Pointer access (que deben ser de la misma gravedad, no los mire), sequidos por otros warnings que en general no son tan importantes aunque pueden mostrar errores de lógica (variable nunca leidas en general).
    No se si la versión fuente que está para descargas es la ultima ultima (había en un tiempo un server svn no?) o si esos warnings los conocen pero saben que no pasa nada (por ej, el doIt que use es protected asi si se redefinio tal vez sea un hecho que jamás se ejecute).
    De paso aprovecho y pregunto si no hay algún servicio para reportar y ver errores (más allá de este foro claro); ya veo que empiezo a comentar cosas que ustedes ya saben de todas maneras.

    #33849
    Federico Cristina
    Superadministrador

    Javier,

    Muchas gracias por tus comentarios. Es verdad que hay ciertos warnings un tanto extraños.

    Justamente como comentás, muchos de ellos tienen varios años ya, pero debido a que inlcuso actualmente no presentan un problema, se minimiza su prioridad dentro del proyecto Libertya.

    Por supuesto que cualquier warning que lleve a comportamiento errático es corregido en un breve lapso de tiempo.

    Específicamente sobre los null pointer access en la clase ImportInvoice: Estos componentes siempre requieren cierta customización en función de los datos a importar y las necesidades del usuario final. Por otra parte, la ejecución de este proceso se da en un momento específico en el uso de la aplicación, con lo cual la lógica funcional del mismo se encuentra bastante aislado.

    Con todo esto no estoy justificando los warnings, sino que los mismos no presentan mayores problemas en el uso de la aplicación, ya que de hacerlo, ya estarían corregidos.

    Saludos!
    Federico

Viendo 2 entradas - de la 1 a la 2 (de un total de 2)
  • Debes estar registrado para responder a este debate.