Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <03c701c33b34$a1bef390$0111010a@user>
From: "Juozas Baliuka" <baliuka@centras.lt>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>,
	<dgraham@apache.org>
References: <20030625154213.58103.qmail@web20711.mail.yahoo.com>
Subject: Re: Checked vs Runtime exceptions
Date: Wed, 25 Jun 2003 18:12:53 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


>
> In many cases that a database operation fails the next layer just cares
> that it gets notified of the failure and logs it (you could also have
> subclasses of MyException that indicate more specific failure types).
> MyException is allowing other layers to be independent of the persistence
> implementation exceptions like SQLException.
>
 Next layer faills too, doe's not it ? If you will handle MyExeption this
way in next layer you will log it twice and
It will dublicate code. I think It is better log all fatal exeptions in
single place, I prefer this way :

void register(MyObject value){

          Connection connection = getConnection();
          updateOrInsert(connection,value);
          log.info(" registred " + value.getId() );

}

The last layer ( resource management ) logs all unhandled exeptions and
releases resources.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 2003.06.21


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org