On error resume... not



  • Found on a mailing list:

    public Object savePatientRegistration(Registration regRec) {
    	try {
    		Session session = HibernateUtil.getSessionFactory().getCurrentSession();
    		Transaction trx = (Transaction)session.beginTransaction();
    		String regId = regRec.getId();
    		if ("".equals(regId)) {
    			regRec.setId(null);
    		}
    
    		Object outputRec = SaveObject102.saveRecordWithTrx(regRec, session, trx);
    		trx.commit();
    		return outputRec;
    	} catch (RuntimeException e) {
    		throw e;
    	}
    }
    


  • Well, he probably decided to bring "data hiding" to a new level: He not just hides fields and helper functions, he really makes sure his internal call stack is hidden, too.

    Brillnt! 



  • @what's-his-name said:

    Why do they always throw away the stack?



  • @PSWorx said:

    Well, he probably decided to bring "data hiding" to a new level: He not just hides fields and helper functions, he really makes sure his internal call stack is hidden, too.

    Brillnt! 

    He isn't actualy throwing away the original stack: he is just throwing the exception. If the original programmer rely wants to dispose the original stacktrace, he must do the folowing:

    throw new RuntimeException(e.getMessage); 

    Most import: the transaction isn't rolledback!
     



  • @salandur said:

    @PSWorx said:

    Well, he probably decided to bring "data hiding" to a new level: He not just hides fields and helper functions, he really makes sure his internal call stack is hidden, too.

    Brillnt! 

    He isn't actualy throwing away the original stack: he is just throwing the exception. If the original programmer rely wants to dispose the original stacktrace, he must do the folowing:

    throw new RuntimeException(e.getMessage); 

    Most import: the transaction isn't rolledback!
     

    That way you also loose the type of the exception (which may be a subclass of RuntimeException).

    To reset the stack, see the fillInStackTrace() method, but please don't use it unless you really know what you're doing! It makes debugging much harder. 



  • @salandur said:

    He isn't actualy throwing away the original stack: he is just throwing the exception.

    For real? I'm not sure about Java, but this would lose the stack trace in C#. To preserve the stack, you'd have to use "throw;" instead of "throw e;"
     



  • @salandur said:

    @PSWorx said:

    Well, he probably decided to bring "data hiding" to a new level: He not just hides fields and helper functions, he really makes sure his internal call stack is hidden, too.

    Brillnt! 

    He isn't actualy throwing away the original stack: he is just throwing the exception. If the original programmer rely wants to dispose the original stacktrace, he must do the folowing:

    throw new RuntimeException(e.getMessage); 

    Most import: the transaction isn't rolledback!
     

    I'm hoping the transaction times out after some time. Because if it doesn't and just keeps like that, wouldn't that leave some tables locked? Thus keeping the application (and any other applications) from working on the locked tables?

    Anyway, even if it times out after a while, it might still hold the lock until the timeout, which could lead to thrown exceptions galore.



  • @bobday said:

    @salandur said:

    He isn't actualy throwing away the original stack: he is just throwing the exception.

    For real? I'm not sure about Java, but this would lose the stack trace in C#. To preserve the stack, you'd have to use "throw;" instead of "throw e;"
     

    In Java, the stack trace is filled in when the exception is created, not when it's thrown.  (Someone already mentioned the way to do it explicitly, but in the vast majority of cases that's done only by the Throwable constructor.)



  • I was baffled and also thought he actually would reset the stack in Java as well, but then I noticed he is simply throwing the same exception he caught. This is an exercise in pointlessness (on the order of if(true || !false && true!=false && 1=1)), but unlike the idiots who simply do "throw new Exception()", at least it's not doing any actual harm.

     (Except to the one reading the code, that is.)


Log in to reply