You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rodney Waldhoff <rw...@apache.org> on 2003/06/24 17:36:24 UTC
[functor] GeneratorException and JDK < 1.4
Jason (and whomever else takes an interest),
The "generator" stuff just added to commons-functor includes a form of
nested/tunneling exception called GeneratorException. This exception, it
seems, is intended to wrap a (checked) Exception, as thrown by specific
Generator instances, in a RuntimeException.
As currently implemented, this adds a dependency on JDK 1.4, since it uses
the RuntimeException(Throwable) constructor. Otherwise, commons-functor
is backward compatiable to JDK 1.2 (or even JDK1.1 with collections).
Two comments on this:
1) I'd like to maintain backward compatiablity with earlier JDKs, if at
all possible. A version of GeneratorException that overloads the
Throwable.getCause method to return a locally defined reference to the
throwable, and doesn't use the super(Throwable) constructor might be one
way to achieve this in a backwards and forwards compatiable fashion
without comprimising the current functionality.
2) GeneratorException begs the question of some sort of generalized
FunctorException and/or a small collection of specific exception types
(PredicateException, ProcedureException, etc.) Alternatively, the
NestedException type in lang could be used for this purpose. Personally,
I'd prefer a specific TunneledException type that is used (and only used)
to adapt Exception to RuntimeException, as I've described at
<http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html>
and elsewhere.
Thoughts? Comments?
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Checked vs Runtime exceptions
Posted by Rodney Waldhoff <rw...@apache.org>.
On Wed, 25 Jun 2003, David Graham wrote:
> Logging was merely an example (probably a poor one).
Agreed. Logging was one of my examples, and it's a bad one for the sake
of this discussion. In practice no logging API I'm aware throws Runtime or
checked Exceptions, but silently fail as far as the calling code is
concerned, and perhaps attempt to report the failure to the user via some
other channel. Indeed given that the actual logging typically happens
asynchronously, this is pretty much the only possible strategy, on top of
being the most desirable one.
For the remainder of this discussion can we drop the logging example?
There's still three (or two, depending upon how you factor it) concrete
examples out there.
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Checked vs Runtime exceptions
Posted by Juozas Baliuka <ba...@centras.lt>.
>
> 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
Re: Checked vs Runtime exceptions
Posted by David Graham <gr...@yahoo.com>.
--- Juozas Baliuka <ba...@centras.lt> wrote:
> Ok,
> next example with checked exception in client code:
>
> void register(MyObject value)throws MyException{
> try{
> Connection connection = getConnection();// Doe's it throws
> SQLException
> too ?
> try{
> updateOrInsert(connection,value);
> log.info(" registred " + value.getId() );
> }finally{
>
> connection.close(); // Doe's the caller better know how to handle
> SQLException wrapped as MyException ?
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.
The commons-sandbox-mapper project provides this exact functionality.
David
>
> }
> }catch(SQLException e){
> throw new MyException(e);
> }// LoggingException is a runtime exeption in this case
>
> }
>
>
> ----- Original Message -----
> From: "David Graham" <gr...@yahoo.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Wednesday, June 25, 2003 4:58 PM
> Subject: Re: Checked vs Runtime exceptions
>
>
> > --- Ryan Hoegg <rh...@isisnetworks.net> wrote:
> > > This may be the "correct solution" in some of your eyes, but it is
> far
> > > too much overhead for most programmers who want to use logging. If
> my
> > > database server is down or the logging directory can not be found
> when I
> > >
> > > want to log something, my application code is not the right place to
> > > handle that.MyMethodUsesLogging has no business handling those
> > > exceptional cases. I think a RuntimeException is most appropriate
> here.
> > >
> >
> > Logging was merely an example (probably a poor one). I don't want to
> > handle exceptions from my logging package but I wouldn't want it to
> throw
> > RuntimeExceptions either (unless I've misused the API).
> >
> > David
> >
> > > Juozas Baliuka wrote:
> > >
> > > > I think this logging example was a good one:
> > > >
> > > > void MyMethodUsesLogging()throws MyException{
> > > > try{
> > > >
> > > > log.info("started");
> > > >
> > > > }catch(LoggingException e){
> > > >
> > > > log.error(e); // ??????????????????
> > > >
> > > > throw new MyExeption(e);
> > > > }
> > > >
> > > >
> > > >}
> > > >
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month!
> > http://sbc.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---
> 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
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Checked vs Runtime exceptions
Posted by Juozas Baliuka <ba...@centras.lt>.
Ok,
next example with checked exception in client code:
void register(MyObject value)throws MyException{
try{
Connection connection = getConnection();// Doe's it throws SQLException
too ?
try{
updateOrInsert(connection,value);
log.info(" registred " + value.getId() );
}finally{
connection.close(); // Doe's the caller better know how to handle
SQLException wrapped as MyException ?
}
}catch(SQLException e){
throw new MyException(e);
}// LoggingException is a runtime exeption in this case
}
----- Original Message -----
From: "David Graham" <gr...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, June 25, 2003 4:58 PM
Subject: Re: Checked vs Runtime exceptions
> --- Ryan Hoegg <rh...@isisnetworks.net> wrote:
> > This may be the "correct solution" in some of your eyes, but it is far
> > too much overhead for most programmers who want to use logging. If my
> > database server is down or the logging directory can not be found when I
> >
> > want to log something, my application code is not the right place to
> > handle that.MyMethodUsesLogging has no business handling those
> > exceptional cases. I think a RuntimeException is most appropriate here.
> >
>
> Logging was merely an example (probably a poor one). I don't want to
> handle exceptions from my logging package but I wouldn't want it to throw
> RuntimeExceptions either (unless I've misused the API).
>
> David
>
> > Juozas Baliuka wrote:
> >
> > > I think this logging example was a good one:
> > >
> > > void MyMethodUsesLogging()throws MyException{
> > > try{
> > >
> > > log.info("started");
> > >
> > > }catch(LoggingException e){
> > >
> > > log.error(e); // ??????????????????
> > >
> > > throw new MyExeption(e);
> > > }
> > >
> > >
> > >}
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---
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
Re: Checked vs Runtime exceptions
Posted by David Graham <gr...@yahoo.com>.
--- Ryan Hoegg <rh...@isisnetworks.net> wrote:
> This may be the "correct solution" in some of your eyes, but it is far
> too much overhead for most programmers who want to use logging. If my
> database server is down or the logging directory can not be found when I
>
> want to log something, my application code is not the right place to
> handle that.MyMethodUsesLogging has no business handling those
> exceptional cases. I think a RuntimeException is most appropriate here.
>
Logging was merely an example (probably a poor one). I don't want to
handle exceptions from my logging package but I wouldn't want it to throw
RuntimeExceptions either (unless I've misused the API).
David
> Juozas Baliuka wrote:
>
> > I think this logging example was a good one:
> >
> > void MyMethodUsesLogging()throws MyException{
> > try{
> >
> > log.info("started");
> >
> > }catch(LoggingException e){
> >
> > log.error(e); // ??????????????????
> >
> > throw new MyExeption(e);
> > }
> >
> >
> >}
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Checked vs Runtime exceptions
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
This may be the "correct solution" in some of your eyes, but it is far
too much overhead for most programmers who want to use logging. If my
database server is down or the logging directory can not be found when I
want to log something, my application code is not the right place to
handle that.MyMethodUsesLogging has no business handling those
exceptional cases. I think a RuntimeException is most appropriate here.
Juozas Baliuka wrote:
> I think this logging example was a good one:
>
> void MyMethodUsesLogging()throws MyException{
> try{
>
> log.info("started");
>
> }catch(LoggingException e){
>
> log.error(e); // ??????????????????
>
> throw new MyExeption(e);
> }
>
>
>}
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Checked vs Runtime exceptions
Posted by Juozas Baliuka <ba...@mwm.lt>.
I think this logging example was a good one:
void MyMethodUsesLogging()throws MyException{
try{
log.info("started");
}catch(LoggingException e){
log.error(e); // ??????????????????
throw new MyExeption(e);
}
}
----- Original Message -----
From: "David Graham" <gr...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, June 25, 2003 1:16 AM
Subject: RE: Checked vs Runtime exceptions
> You missed the correct solution in your logging
> example. Obviously, various implementations will
> throw different sets of exceptions so the right way to
> handle it is to create a checked LoggingException and
> throw that from the log methods. The implementations
> will wrap their exceptions in LoggingExceptions. This
> keeps all of the advantages of checked exception
> handling without resorting to throwing/catching
> Exception.
>
> RuntimeExceptions indicate programmer error. In rare
> cases they are thrown when you must bypass several
> application layers (see SecurityException for an
> example).
>
> David
>
> --- Rodney Waldhoff <rw...@apache.org> wrote:
> > I'm not sure that "ownership" necessarily enters
> > into it, but here's some
> > concrete examples:
> >
> > Consider a simple logging API:
> >
> > interface Log {
> > void debug(String message);
> > void info(String message);
> > void fatal(String message);
> > }
> >
> > One implementation of that interface might write the
> > output to standard
> > out. Since System.out (java.io.PrintStream I guess)
> > never throws a
> > checked exception, there's no need to ever throw a
> > checked exception from
> > that implementation or that interface.
> >
> > Another implementation of that interface might write
> > to some external
> > file. Any of those write calls might throw an
> > IOException, in which case
> > I should add "throws IOException" to all of my
> > logging methods unless I'm
> > gonna swallow all of those exceptions (while
> > swallowing exceptions *might*
> > be OK in the logging case, it certainly isn't OK in
> > the general case).
> >
> > interface Log {
> > void debug(String message) throws IOException;
> > void info(String message) throws IOException;
> > void fatal(String message) throws IOException;
> > }
> >
> > Now even if I'm using a System.out logger, I've got
> > to catch or throw
> > IOException, just in case.
> >
> > Yet another implementation of that interface might
> > write log messages to a
> > database. Any of those insert statements might
> > throw a SQLException, in
> > which case I should add "throws SQLException" to all
> > my logging methods:
> >
> > interface Log {
> > void debug(String message) throws IOException,
> > SQLException;
> > void info(String message) throws IOException,
> > SQLException;
> > void fatal(String message) throws IOException,
> > SQLException;
> > }
> >
> > Of course, I'll never be able to anticipate all of
> > the specific types of
> > Exception that might be thrown. I may as well drop
> > back to the general
> > case:
> >
> > interface Log {
> > void debug(String message) throws Exception;
> > void info(String message) throws Exception;
> > void fatal(String message) throws Exception;
> > }
> >
> > but now I have all of the disadvantages of checked
> > exceptions--I need to
> > explictly catch or throw Exception every time I
> > invoke one of these
> > methods--but none of the advantages of checked
> > exceptions--I don't have
> > any guarentee that the specific type of exception
> > that might be throw by
> > the implementation code is going to be specifically
> > handled by the calling
> > code. How's this any better than RuntimeException?
> >
> > As another example, consider java.util.Iterator. I
> > can do lots of useful
> > things with Iterators (chain them, filter them,
> > transform them, apply some
> > function to each element within the iteration,
> > etc.). One source of
> > Iterators is the Collections API. But it's not
> > difficult to create an
> > Iterator from other sources--say an Iterator over
> > the lines in a file:
> >
> > class LineIterator implements Iterator {
> > LineIterator(BufferedReader reader) {
> > this.reader = reader;
> > }
> >
> > Object next() {
> > if(hasNext()) {
> > nextSet = false;
> > return nextLine;
> > } else {
> > throw new NoSuchElementException();
> > }
> > }
> >
> > boolean hasNext() {
> > if(!nextSet) {
> > setNext();
> > }
> > return nextLine != null;
> > }
> >
> > private setNext() throws IOException {
> > nextLine = reader.readLine();
> > nextSet = true;
> > }
> >
> > private Reader reader;
> > private String nextLine;
> > private boolean nextSet = false;
> > }
> >
> > or the values in some column in a database table:
> >
> > class ColumnIterator implements Iterator {
> > ColumnIterator(ResultSet rset, int column) {
> > this.rset = rset;
> > this.column = column;
> > }
> >
> > Object next() {
> > if(hasNext()) {
> > nextSet = false;
> > return next;
> > } else {
> > throw new NoSuchElementException();
> > }
> > }
> >
> > boolean hasNext() {
> > if(!nextSet) {
> > setNext();
> > }
> > return nextSet;
> > }
> >
> > private setNext() throws SQLException {
> > if(rset.next()) {
> > next = rset.getString(column);
> > nextSet = true;
> > } else {
> > nextSet = false;
> > }
> > }
> >
> > private ResultSet rset;
> > private int column;
> > private Object next;
> > private boolean nextSet = false;
> > }
> >
> > Of course, those don't quite work because the
> > checked IOExceptions and
> > SQLExceptions aren't being handled. In theory, one
> > could add "throws
> > Exception" to all of the Iterator methods (subject
> > to the limitations
> > above), but in practice that's not going to happen.
> >
> > Why not just throw RuntimeException in this case
> > (and ignore the tunneling
> > concept)? Because there are times when I might be
> > able to handle or
> > announce the underlying cause:
> >
> > // process the commands in the given stream,
> > ignoring lines that start
> > with #
> > void processCommandStream(Reader in) throws
> > IOException {
> > UnaryPredicate startsWithHash = new
> > UnaryPredicate() {
> > public boolean evaluate(Object obj) {
> > return ((String)obj).startsWith("#");
> > }
> > }
> >
> > Iterator iterator = new FilteringIterator(
> > new NotPredicate(startsWithHash),
> > new LineIterator(in));
> >
> > try {
> > while(iterator.hasNext()) {
> > processCommand((String)iterator.next());
> > }
> > } catch(TunneledException e) {
> > if(e.getException() instanceof IOException) {
> > throw (IOException)(e.getException());
> > }
> > }
> >
> === message truncated ===
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Checked vs Runtime exceptions
Posted by Rodney Waldhoff <rw...@apache.org>.
On Tue, 24 Jun 2003, David Graham wrote:
> RuntimeExceptions indicate programmer error.
I'll agree with that.
> In rare
> cases they are thrown when you must bypass several
> application layers (see SecurityException for an
> example).
Precisely. And sometimes you must bypass several (one or more)
application layers without knowledge of the underlying type of exception.
That's the role of TunneledException in my mind. Frameworks like
commons-pool, and to a greater extent, commons-functor, are likely to fall
into this situation. Framework specific wrappers (PoolException,
FunctorException), but seem, well, redudant, but more importantly explode
in complexity when the framworks are composed. (E.g., if I have a functor
based pool, will pool throw PoolException wrapping FunctorException
wrapping Exception, or will the pool unwrap the underlying Exception and
wrap it in the PoolException? Does the calling code need to know?)
I'm not suggesting that every place we throw a checked Exception we should
convert it to a wrapped RuntimeException, but I am suggesting that any
place we've got or might want "throws Exception" a less verbose solution
*might* be appropriate.
- Rod <http://radio.weblogs.com/0122027/>
>
> David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Checked vs Runtime exceptions
Posted by Juozas Baliuka <ba...@mwm.lt>.
Checked exeptions look very usefull for API designers and useless for API
users, doe's not it ?
> You missed the correct solution in your logging
> example. Obviously, various implementations will
> throw different sets of exceptions so the right way to
> handle it is to create a checked LoggingException and
> throw that from the log methods. The implementations
> will wrap their exceptions in LoggingExceptions. This
> keeps all of the advantages of checked exception
> handling without resorting to throwing/catching
> Exception.
>
> RuntimeExceptions indicate programmer error. In rare
> cases they are thrown when you must bypass several
> application layers (see SecurityException for an
> example).
>
> David
>
> --- Rodney Waldhoff <rw...@apache.org> wrote:
> > I'm not sure that "ownership" necessarily enters
> > into it, but here's some
> > concrete examples:
> >
> > Consider a simple logging API:
> >
> > interface Log {
> > void debug(String message);
> > void info(String message);
> > void fatal(String message);
> > }
> >
> > One implementation of that interface might write the
> > output to standard
> > out. Since System.out (java.io.PrintStream I guess)
> > never throws a
> > checked exception, there's no need to ever throw a
> > checked exception from
> > that implementation or that interface.
> >
> > Another implementation of that interface might write
> > to some external
> > file. Any of those write calls might throw an
> > IOException, in which case
> > I should add "throws IOException" to all of my
> > logging methods unless I'm
> > gonna swallow all of those exceptions (while
> > swallowing exceptions *might*
> > be OK in the logging case, it certainly isn't OK in
> > the general case).
> >
> > interface Log {
> > void debug(String message) throws IOException;
> > void info(String message) throws IOException;
> > void fatal(String message) throws IOException;
> > }
> >
> > Now even if I'm using a System.out logger, I've got
> > to catch or throw
> > IOException, just in case.
> >
> > Yet another implementation of that interface might
> > write log messages to a
> > database. Any of those insert statements might
> > throw a SQLException, in
> > which case I should add "throws SQLException" to all
> > my logging methods:
> >
> > interface Log {
> > void debug(String message) throws IOException,
> > SQLException;
> > void info(String message) throws IOException,
> > SQLException;
> > void fatal(String message) throws IOException,
> > SQLException;
> > }
> >
> > Of course, I'll never be able to anticipate all of
> > the specific types of
> > Exception that might be thrown. I may as well drop
> > back to the general
> > case:
> >
> > interface Log {
> > void debug(String message) throws Exception;
> > void info(String message) throws Exception;
> > void fatal(String message) throws Exception;
> > }
> >
> > but now I have all of the disadvantages of checked
> > exceptions--I need to
> > explictly catch or throw Exception every time I
> > invoke one of these
> > methods--but none of the advantages of checked
> > exceptions--I don't have
> > any guarentee that the specific type of exception
> > that might be throw by
> > the implementation code is going to be specifically
> > handled by the calling
> > code. How's this any better than RuntimeException?
> >
> > As another example, consider java.util.Iterator. I
> > can do lots of useful
> > things with Iterators (chain them, filter them,
> > transform them, apply some
> > function to each element within the iteration,
> > etc.). One source of
> > Iterators is the Collections API. But it's not
> > difficult to create an
> > Iterator from other sources--say an Iterator over
> > the lines in a file:
> >
> > class LineIterator implements Iterator {
> > LineIterator(BufferedReader reader) {
> > this.reader = reader;
> > }
> >
> > Object next() {
> > if(hasNext()) {
> > nextSet = false;
> > return nextLine;
> > } else {
> > throw new NoSuchElementException();
> > }
> > }
> >
> > boolean hasNext() {
> > if(!nextSet) {
> > setNext();
> > }
> > return nextLine != null;
> > }
> >
> > private setNext() throws IOException {
> > nextLine = reader.readLine();
> > nextSet = true;
> > }
> >
> > private Reader reader;
> > private String nextLine;
> > private boolean nextSet = false;
> > }
> >
> > or the values in some column in a database table:
> >
> > class ColumnIterator implements Iterator {
> > ColumnIterator(ResultSet rset, int column) {
> > this.rset = rset;
> > this.column = column;
> > }
> >
> > Object next() {
> > if(hasNext()) {
> > nextSet = false;
> > return next;
> > } else {
> > throw new NoSuchElementException();
> > }
> > }
> >
> > boolean hasNext() {
> > if(!nextSet) {
> > setNext();
> > }
> > return nextSet;
> > }
> >
> > private setNext() throws SQLException {
> > if(rset.next()) {
> > next = rset.getString(column);
> > nextSet = true;
> > } else {
> > nextSet = false;
> > }
> > }
> >
> > private ResultSet rset;
> > private int column;
> > private Object next;
> > private boolean nextSet = false;
> > }
> >
> > Of course, those don't quite work because the
> > checked IOExceptions and
> > SQLExceptions aren't being handled. In theory, one
> > could add "throws
> > Exception" to all of the Iterator methods (subject
> > to the limitations
> > above), but in practice that's not going to happen.
> >
> > Why not just throw RuntimeException in this case
> > (and ignore the tunneling
> > concept)? Because there are times when I might be
> > able to handle or
> > announce the underlying cause:
> >
> > // process the commands in the given stream,
> > ignoring lines that start
> > with #
> > void processCommandStream(Reader in) throws
> > IOException {
> > UnaryPredicate startsWithHash = new
> > UnaryPredicate() {
> > public boolean evaluate(Object obj) {
> > return ((String)obj).startsWith("#");
> > }
> > }
> >
> > Iterator iterator = new FilteringIterator(
> > new NotPredicate(startsWithHash),
> > new LineIterator(in));
> >
> > try {
> > while(iterator.hasNext()) {
> > processCommand((String)iterator.next());
> > }
> > } catch(TunneledException e) {
> > if(e.getException() instanceof IOException) {
> > throw (IOException)(e.getException());
> > }
> > }
> >
> === message truncated ===
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Checked vs Runtime exceptions
Posted by David Graham <gr...@yahoo.com>.
You missed the correct solution in your logging
example. Obviously, various implementations will
throw different sets of exceptions so the right way to
handle it is to create a checked LoggingException and
throw that from the log methods. The implementations
will wrap their exceptions in LoggingExceptions. This
keeps all of the advantages of checked exception
handling without resorting to throwing/catching
Exception.
RuntimeExceptions indicate programmer error. In rare
cases they are thrown when you must bypass several
application layers (see SecurityException for an
example).
David
--- Rodney Waldhoff <rw...@apache.org> wrote:
> I'm not sure that "ownership" necessarily enters
> into it, but here's some
> concrete examples:
>
> Consider a simple logging API:
>
> interface Log {
> void debug(String message);
> void info(String message);
> void fatal(String message);
> }
>
> One implementation of that interface might write the
> output to standard
> out. Since System.out (java.io.PrintStream I guess)
> never throws a
> checked exception, there's no need to ever throw a
> checked exception from
> that implementation or that interface.
>
> Another implementation of that interface might write
> to some external
> file. Any of those write calls might throw an
> IOException, in which case
> I should add "throws IOException" to all of my
> logging methods unless I'm
> gonna swallow all of those exceptions (while
> swallowing exceptions *might*
> be OK in the logging case, it certainly isn't OK in
> the general case).
>
> interface Log {
> void debug(String message) throws IOException;
> void info(String message) throws IOException;
> void fatal(String message) throws IOException;
> }
>
> Now even if I'm using a System.out logger, I've got
> to catch or throw
> IOException, just in case.
>
> Yet another implementation of that interface might
> write log messages to a
> database. Any of those insert statements might
> throw a SQLException, in
> which case I should add "throws SQLException" to all
> my logging methods:
>
> interface Log {
> void debug(String message) throws IOException,
> SQLException;
> void info(String message) throws IOException,
> SQLException;
> void fatal(String message) throws IOException,
> SQLException;
> }
>
> Of course, I'll never be able to anticipate all of
> the specific types of
> Exception that might be thrown. I may as well drop
> back to the general
> case:
>
> interface Log {
> void debug(String message) throws Exception;
> void info(String message) throws Exception;
> void fatal(String message) throws Exception;
> }
>
> but now I have all of the disadvantages of checked
> exceptions--I need to
> explictly catch or throw Exception every time I
> invoke one of these
> methods--but none of the advantages of checked
> exceptions--I don't have
> any guarentee that the specific type of exception
> that might be throw by
> the implementation code is going to be specifically
> handled by the calling
> code. How's this any better than RuntimeException?
>
> As another example, consider java.util.Iterator. I
> can do lots of useful
> things with Iterators (chain them, filter them,
> transform them, apply some
> function to each element within the iteration,
> etc.). One source of
> Iterators is the Collections API. But it's not
> difficult to create an
> Iterator from other sources--say an Iterator over
> the lines in a file:
>
> class LineIterator implements Iterator {
> LineIterator(BufferedReader reader) {
> this.reader = reader;
> }
>
> Object next() {
> if(hasNext()) {
> nextSet = false;
> return nextLine;
> } else {
> throw new NoSuchElementException();
> }
> }
>
> boolean hasNext() {
> if(!nextSet) {
> setNext();
> }
> return nextLine != null;
> }
>
> private setNext() throws IOException {
> nextLine = reader.readLine();
> nextSet = true;
> }
>
> private Reader reader;
> private String nextLine;
> private boolean nextSet = false;
> }
>
> or the values in some column in a database table:
>
> class ColumnIterator implements Iterator {
> ColumnIterator(ResultSet rset, int column) {
> this.rset = rset;
> this.column = column;
> }
>
> Object next() {
> if(hasNext()) {
> nextSet = false;
> return next;
> } else {
> throw new NoSuchElementException();
> }
> }
>
> boolean hasNext() {
> if(!nextSet) {
> setNext();
> }
> return nextSet;
> }
>
> private setNext() throws SQLException {
> if(rset.next()) {
> next = rset.getString(column);
> nextSet = true;
> } else {
> nextSet = false;
> }
> }
>
> private ResultSet rset;
> private int column;
> private Object next;
> private boolean nextSet = false;
> }
>
> Of course, those don't quite work because the
> checked IOExceptions and
> SQLExceptions aren't being handled. In theory, one
> could add "throws
> Exception" to all of the Iterator methods (subject
> to the limitations
> above), but in practice that's not going to happen.
>
> Why not just throw RuntimeException in this case
> (and ignore the tunneling
> concept)? Because there are times when I might be
> able to handle or
> announce the underlying cause:
>
> // process the commands in the given stream,
> ignoring lines that start
> with #
> void processCommandStream(Reader in) throws
> IOException {
> UnaryPredicate startsWithHash = new
> UnaryPredicate() {
> public boolean evaluate(Object obj) {
> return ((String)obj).startsWith("#");
> }
> }
>
> Iterator iterator = new FilteringIterator(
> new NotPredicate(startsWithHash),
> new LineIterator(in));
>
> try {
> while(iterator.hasNext()) {
> processCommand((String)iterator.next());
> }
> } catch(TunneledException e) {
> if(e.getException() instanceof IOException) {
> throw (IOException)(e.getException());
> }
> }
>
=== message truncated ===
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Checked vs Runtime exceptions
Posted by Rodney Waldhoff <rw...@apache.org>.
I'm not sure that "ownership" necessarily enters into it, but here's some
concrete examples:
Consider a simple logging API:
interface Log {
void debug(String message);
void info(String message);
void fatal(String message);
}
One implementation of that interface might write the output to standard
out. Since System.out (java.io.PrintStream I guess) never throws a
checked exception, there's no need to ever throw a checked exception from
that implementation or that interface.
Another implementation of that interface might write to some external
file. Any of those write calls might throw an IOException, in which case
I should add "throws IOException" to all of my logging methods unless I'm
gonna swallow all of those exceptions (while swallowing exceptions *might*
be OK in the logging case, it certainly isn't OK in the general case).
interface Log {
void debug(String message) throws IOException;
void info(String message) throws IOException;
void fatal(String message) throws IOException;
}
Now even if I'm using a System.out logger, I've got to catch or throw
IOException, just in case.
Yet another implementation of that interface might write log messages to a
database. Any of those insert statements might throw a SQLException, in
which case I should add "throws SQLException" to all my logging methods:
interface Log {
void debug(String message) throws IOException, SQLException;
void info(String message) throws IOException, SQLException;
void fatal(String message) throws IOException, SQLException;
}
Of course, I'll never be able to anticipate all of the specific types of
Exception that might be thrown. I may as well drop back to the general
case:
interface Log {
void debug(String message) throws Exception;
void info(String message) throws Exception;
void fatal(String message) throws Exception;
}
but now I have all of the disadvantages of checked exceptions--I need to
explictly catch or throw Exception every time I invoke one of these
methods--but none of the advantages of checked exceptions--I don't have
any guarentee that the specific type of exception that might be throw by
the implementation code is going to be specifically handled by the calling
code. How's this any better than RuntimeException?
As another example, consider java.util.Iterator. I can do lots of useful
things with Iterators (chain them, filter them, transform them, apply some
function to each element within the iteration, etc.). One source of
Iterators is the Collections API. But it's not difficult to create an
Iterator from other sources--say an Iterator over the lines in a file:
class LineIterator implements Iterator {
LineIterator(BufferedReader reader) {
this.reader = reader;
}
Object next() {
if(hasNext()) {
nextSet = false;
return nextLine;
} else {
throw new NoSuchElementException();
}
}
boolean hasNext() {
if(!nextSet) {
setNext();
}
return nextLine != null;
}
private setNext() throws IOException {
nextLine = reader.readLine();
nextSet = true;
}
private Reader reader;
private String nextLine;
private boolean nextSet = false;
}
or the values in some column in a database table:
class ColumnIterator implements Iterator {
ColumnIterator(ResultSet rset, int column) {
this.rset = rset;
this.column = column;
}
Object next() {
if(hasNext()) {
nextSet = false;
return next;
} else {
throw new NoSuchElementException();
}
}
boolean hasNext() {
if(!nextSet) {
setNext();
}
return nextSet;
}
private setNext() throws SQLException {
if(rset.next()) {
next = rset.getString(column);
nextSet = true;
} else {
nextSet = false;
}
}
private ResultSet rset;
private int column;
private Object next;
private boolean nextSet = false;
}
Of course, those don't quite work because the checked IOExceptions and
SQLExceptions aren't being handled. In theory, one could add "throws
Exception" to all of the Iterator methods (subject to the limitations
above), but in practice that's not going to happen.
Why not just throw RuntimeException in this case (and ignore the tunneling
concept)? Because there are times when I might be able to handle or
announce the underlying cause:
// process the commands in the given stream, ignoring lines that start
with #
void processCommandStream(Reader in) throws IOException {
UnaryPredicate startsWithHash = new UnaryPredicate() {
public boolean evaluate(Object obj) {
return ((String)obj).startsWith("#");
}
}
Iterator iterator = new FilteringIterator(
new NotPredicate(startsWithHash),
new LineIterator(in));
try {
while(iterator.hasNext()) {
processCommand((String)iterator.next());
}
} catch(TunneledException e) {
if(e.getException() instanceof IOException) {
throw (IOException)(e.getException());
}
}
}
- Rod <http://radio.weblogs.com/0122027/>
On Tue, 24 Jun 2003, David Graham wrote:
> > I see his proposed technique as being useful in the case where we own
> > layers
> > A and C, and need to get through layer B in the cleanest way, where
> > layer B
> > doesn't expose a proper middleware understanding of exception handling.
> > I
> > would not want to see new middleware use his proposal as an "excuse" not
> > to
> > provide for checked exceptions in the interface.
>
> Can you provide a concrete example of layers A, B, and C? A
> RuntimeException wrapping a checked exception class may be useful in some
> cases but adding it to commons implies that Jakarta Commons supports poor
> programming practices.
>
> David
>
> >
> > --- Noel
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Checked vs Runtime exceptions
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I see his proposed technique as being useful in the case where we own
> > layers A and C, and need to get through layer B in the cleanest way,
> > where layer B doesn't expose a proper middleware understanding of
> > exception handling. I would not want to see new middleware use his
> > proposal as an "excuse" not to provide for checked exceptions in the
> > interface.
> A RuntimeException wrapping a checked exception class may be useful
> in some cases but adding it to commons implies that Jakarta Commons
> supports poor programming practices.
Wait a second. :-) I think we're losing some context here. I am not
proposing or defending the use of RuntimeException in Commons (or anywhere
else). I tend to spend time removing the things from code, when I can, not
adding them. The context to which I was responding is here:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apac
he.org&msgNo=29355
which proposes this technique of using of a RuntimeException to "tunnel"
checked exceptions through an existing interface. As I said in my very
first sentence, I don't agree with his overall analysis regarding checked
exceptions, but I do see a limited use for his technique (above), and I just
wanted to know if this was something that was being proposed for use in
Commons for reuse elsewhere, or if each project would create their own
wrapper if/when necessary.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Checked vs Runtime exceptions
Posted by David Graham <gr...@yahoo.com>.
> I see his proposed technique as being useful in the case where we own
> layers
> A and C, and need to get through layer B in the cleanest way, where
> layer B
> doesn't expose a proper middleware understanding of exception handling.
> I
> would not want to see new middleware use his proposal as an "excuse" not
> to
> provide for checked exceptions in the interface.
Can you provide a concrete example of layers A, B, and C? A
RuntimeException wrapping a checked exception class may be useful in some
cases but adding it to commons implies that Jakarta Commons supports poor
programming practices.
David
>
> --- Noel
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Checked vs Runtime exceptions
Posted by "Noel J. Bergman" <no...@devtech.com>.
David,
>>
http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWe
reAMistake.html
>> Although I don't entirely agree with the analysis, I do agree that the
>> proposed technique can be useful. Is this exception going to be added
>> somewhere to Jakarta-Commons for general use? Where will it be packaged
>> for re-use?
> It would be sad to see the Commons start using RuntimeExceptions
> everywhere as it's a really poor design technique.
Personally, I dislike runtime exceptions. They are the source of far too
many errors in far too much code. Whenever possible, I always code checked
exceptions. Unfortunately, not everyone does, and particularly prior to
nested exceptions, most code didn't know what to do about passing up
exceptions that weren't declared in the throws clause.
JavaMail's MessagingException, for example, is a checked exception that
nests any underlying exceptions that led to the MessagingException. It is,
from that perspective, similar to the proposed solution, except that it is
checked.
> The reasoning for such an approach seems to be, "Pool throws unchecked
> exceptions and DBCP doesn't so we need a wrapper." In that case, pool is
> in error, not DBCP.
I see his proposed technique as being useful in the case where we own layers
A and C, and need to get through layer B in the cleanest way, where layer B
doesn't expose a proper middleware understanding of exception handling. I
would not want to see new middleware use his proposal as an "excuse" not to
provide for checked exceptions in the interface.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Checked vs Runtime exceptions
Posted by David Graham <gr...@yahoo.com>.
--- "Noel J. Bergman" <no...@devtech.com> wrote:
> re:
>
http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWe
> reAMistake.html
>
> Although I don't entirely agree with the analysis, I do agree that the
> proposed technique can be useful. Is this exception going to be added
> somewhere to Jakarta-Commons for general use? Where will it be packaged
> for
> re-use?
The reasoning for such an approach seems to be, "Pool throws unchecked
exceptions and DBCP doesn't so we need a wrapper." In that case, pool is
in error, not DBCP.
It would be sad to see the Commons start using RuntimeExceptions
everywhere as it's a really poor design technique.
David
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Checked vs Runtime exceptions
Posted by "Noel J. Bergman" <no...@devtech.com>.
re:
http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWe
reAMistake.html
Although I don't entirely agree with the analysis, I do agree that the
proposed technique can be useful. Is this exception going to be added
somewhere to Jakarta-Commons for general use? Where will it be packaged for
re-use?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [functor] GeneratorException and JDK < 1.4
Posted by Jason Horman <ja...@jhorman.org>.
Your right, oops. I haven't thought about JDK <1.4 in a while.
I do think that a FunctorException would be valuable. The ability to catch
exceptions thrown from functor, or any library, separately from other Runtime
exceptions seems important. For now FunctorException could be a simple extension
of TunneledException or NestedException. GeneratorException could then be
removed, or it could be an extension of FunctorException.
I am in total agreement with you about checked Exceptions by the way. It bites
you in particular when dealing with high level interfaces or abstract classes.
I have some additional "generators" but I am not sure where the best place for
them is. For example, I have a generator for xml nodes that looks like this:
new EachNode(xml, "/root/path/to/nodes[@id > 10]").select(pred).apply(func);
This generator creates a dependency to dom4j (or whatever parser we want), which
I assume you don't want. Would you see something like this living in the dom4j
repository? Or maybe a separate maven target could build functor with optional
generators/packages, like jelly seems to be doing.
-jason
-----Original Message-----
From: Rodney Waldhoff [mailto:rwaldhoff@apache.org]
Sent: Tuesday, June 24, 2003 11:36 AM
To: commons-dev@jakarta.apache.org
Subject: [functor] GeneratorException and JDK < 1.4
Jason (and whomever else takes an interest),
The "generator" stuff just added to commons-functor includes a form of
nested/tunneling exception called GeneratorException. This exception, it
seems, is intended to wrap a (checked) Exception, as thrown by specific
Generator instances, in a RuntimeException.
As currently implemented, this adds a dependency on JDK 1.4, since it uses
the RuntimeException(Throwable) constructor. Otherwise, commons-functor
is backward compatiable to JDK 1.2 (or even JDK1.1 with collections).
Two comments on this:
1) I'd like to maintain backward compatiablity with earlier JDKs, if at
all possible. A version of GeneratorException that overloads the
Throwable.getCause method to return a locally defined reference to the
throwable, and doesn't use the super(Throwable) constructor might be one
way to achieve this in a backwards and forwards compatiable fashion
without comprimising the current functionality.
2) GeneratorException begs the question of some sort of generalized
FunctorException and/or a small collection of specific exception types
(PredicateException, ProcedureException, etc.) Alternatively, the
NestedException type in lang could be used for this purpose. Personally,
I'd prefer a specific TunneledException type that is used (and only used)
to adapt Exception to RuntimeException, as I've described at
<http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereA
Mistake.html>
and elsewhere.
Thoughts? Comments?
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org