[VFS] Softening the exceptions...

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VFS] Softening the exceptions...

James Carman
What do you folks think about making the exceptions extend
RuntimeException in 2.0?  I really find it tedious to do try/catch
everywhere I want to ask a FileObject something (like if it exists or
not).

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Steve Siebert
+1 on this issue.

I use VFS on a couple projects and this is always a bit burdensome, and on
several occasions have indeed caught and rethrew RuntimeExceptions.  Even if
we can't/shouldn't soften them, what about typing them to be more specific?
 Having every method throwing a FileSystemException isn't always the most
helpful =)

Steve

On Mon, Oct 25, 2010 at 10:46 AM, James Carman
<[hidden email]>wrote:

> What do you folks think about making the exceptions extend
> RuntimeException in 2.0?  I really find it tedious to do try/catch
> everywhere I want to ask a FileObject something (like if it exists or
> not).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

James Carman
I've even gone as far as writing a VfsUtils class that does all the
wrapping of these exceptions into RuntimeExceptions so that the API is
less of a burden.

On Mon, Oct 25, 2010 at 10:53 AM, Steven Siebert <[hidden email]> wrote:

> +1 on this issue.
>
> I use VFS on a couple projects and this is always a bit burdensome, and on
> several occasions have indeed caught and rethrew RuntimeExceptions.  Even if
> we can't/shouldn't soften them, what about typing them to be more specific?
>  Having every method throwing a FileSystemException isn't always the most
> helpful =)
>
> Steve
>
> On Mon, Oct 25, 2010 at 10:46 AM, James Carman
> <[hidden email]>wrote:
>
>> What do you folks think about making the exceptions extend
>> RuntimeException in 2.0?  I really find it tedious to do try/catch
>> everywhere I want to ask a FileObject something (like if it exists or
>> not).
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [VFS] Softening the exceptions...

Gary Gregory
Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places?

I am worried that we would make all APIs "quiet" (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir)

OTOH, I do not know if the java.io API is perfect WRT exceptions.

Gary Gregory
Senior Software Engineer
Rocket Software
3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA
Tel: +1.404.760.1560
Email: [hidden email]
Web: seagull.rocketsoftware.com 



> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of James Carman
> Sent: Monday, October 25, 2010 07:56
> To: Commons Developers List
> Subject: Re: [VFS] Softening the exceptions...
>
> I've even gone as far as writing a VfsUtils class that does all the
> wrapping of these exceptions into RuntimeExceptions so that the API is
> less of a burden.
>
> On Mon, Oct 25, 2010 at 10:53 AM, Steven Siebert <[hidden email]> wrote:
> > +1 on this issue.
> >
> > I use VFS on a couple projects and this is always a bit burdensome, and on
> > several occasions have indeed caught and rethrew RuntimeExceptions.  Even if
> > we can't/shouldn't soften them, what about typing them to be more specific?
> >  Having every method throwing a FileSystemException isn't always the most
> > helpful =)
> >
> > Steve
> >
> > On Mon, Oct 25, 2010 at 10:46 AM, James Carman
> > <[hidden email]>wrote:
> >
> >> What do you folks think about making the exceptions extend
> >> RuntimeException in 2.0?  I really find it tedious to do try/catch
> >> everywhere I want to ask a FileObject something (like if it exists or
> >> not).
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

James Carman
On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
<[hidden email]> wrote:
> Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places?
>

Definitely quieter than java.io.File!  I *hate* that API for its
checked exceptions.

> I am worried that we would make all APIs "quiet" (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir)
>

I'm one of those folks who think the checked exceptions are evil, so I
am fine with getting rid of them entirely (think about how much nicer
your Hibernate code looks without the checked exceptions).  Boolean
returns are fine I guess.  No real strong opinion on that one.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Ralph Goers

On Oct 25, 2010, at 8:10 AM, James Carman wrote:

> On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
> <[hidden email]> wrote:
>> Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places?
>>
>
> Definitely quieter than java.io.File!  I *hate* that API for its
> checked exceptions.
>
>> I am worried that we would make all APIs "quiet" (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir)
>>
>
> I'm one of those folks who think the checked exceptions are evil, so I
> am fine with getting rid of them entirely (think about how much nicer
> your Hibernate code looks without the checked exceptions).  Boolean
> returns are fine I guess.  No real strong opinion on that one.
>

I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes.  

Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Steve Siebert
true =)  BTW, I'll be at ApacheCon, if the VFS crew would like another warm
body to assist in getting the release out.  Just let me know when/where to
be

On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers <[hidden email]>wrote:

>
> On Oct 25, 2010, at 8:10 AM, James Carman wrote:
>
> > On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
> > <[hidden email]> wrote:
> >> Do we want the APIs to be quieter than using java.io.File for example?
> Or, should exceptions be thrown from similar places?
> >>
> >
> > Definitely quieter than java.io.File!  I *hate* that API for its
> > checked exceptions.
> >
> >> I am worried that we would make all APIs "quiet" (unchecked exceptions)
> as a opposed to really thinking where exceptions should be checked or return
> an Boolean error code (like File mkdir)
> >>
> >
> > I'm one of those folks who think the checked exceptions are evil, so I
> > am fine with getting rid of them entirely (think about how much nicer
> > your Hibernate code looks without the checked exceptions).  Boolean
> > returns are fine I guess.  No real strong opinion on that one.
> >
>
> I'm not in favor of changing much at this point. I'd really like to get a
> release done without too many more changes.
>
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Paul Benedict
In reply to this post by Ralph Goers
+1 for softening all exceptions. The fact is, what reasonable recourse
is there to the user if a file operation fails? That's what checked
exceptions were supposed to be for -- mandate handling code. It's
tough to say we need to mandate handling these errors.

Paul

On Mon, Oct 25, 2010 at 10:49 AM, Ralph Goers
<[hidden email]> wrote:

>
> On Oct 25, 2010, at 8:10 AM, James Carman wrote:
>
>> On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
>> <[hidden email]> wrote:
>>> Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places?
>>>
>>
>> Definitely quieter than java.io.File!  I *hate* that API for its
>> checked exceptions.
>>
>>> I am worried that we would make all APIs "quiet" (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir)
>>>
>>
>> I'm one of those folks who think the checked exceptions are evil, so I
>> am fine with getting rid of them entirely (think about how much nicer
>> your Hibernate code looks without the checked exceptions).  Boolean
>> returns are fine I guess.  No real strong opinion on that one.
>>
>
> I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes.
>
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

James Carman
In reply to this post by Ralph Goers
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
<[hidden email]> wrote:
> I'm not in favor of changing much at this point. I'd really like to get a release done without too many more changes.
>

There's a problem with that, Ralph.  If we publish a 2.0, we can't
"break" the API later.  So, we'd have to go to 3.0 if we wanted to
break anything.  So, we need to figure out if this is the way we want
to go and do it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Mark Fortner-3
-1

At the risk of playing Devils Advocate here, what's the downside to checked
exceptions? A few extra lines of code?  I can foresee a problem with
unchecked exceptions though.  Imagine that you're using the API to build a
desktop application.  You want to display a dialog box to the user
indicating that some problem has occurred.  With an unchecked exception, the
stack trace and exception message may appear in a log file or in the
console, but the user would in all likelihood never see it.

Moreover if a developer is unfamiliar with the API, with a checked
exception, they would be able to make an informed decision about how to
handle the exception. The developer can easily trap the exception, and
display a semi-informative dialog indicating that something has gone wrong.
 Although the user may not be able to fix it, they would still know that a
problem occurred, and would hopefully be able to file a bug report to that
effect. If you don't want the user informed, you can always swallow the
exception. But at least, as a developer, you have a choice about how to deal
with it, and it's not something that just pops up out of no where and
surprises both user and developer.

Mark

card.ly: <http://card.ly/phidias51>


On Mon, Oct 25, 2010 at 9:01 AM, James Carman <[hidden email]>wrote:

> On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
> <[hidden email]> wrote:
> > I'm not in favor of changing much at this point. I'd really like to get a
> release done without too many more changes.
> >
>
> There's a problem with that, Ralph.  If we publish a 2.0, we can't
> "break" the API later.  So, we'd have to go to 3.0 if we wanted to
> break anything.  So, we need to figure out if this is the way we want
> to go and do it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Steve Siebert
I agree with Mark's point about unfamiliar developers benefiting from
checked exceptions.  Unlike James, I like checked exceptions =), and I have
established "elegant" recoveries from various resource exceptions (IO, for
example) under many use cases (at least in the enterprise arena).

What's everyones opinion on more "descriptive" Exception typing to allow me
to handle specific failures easier (without additional testing)?  I can
probably go through my code and find some examples if necessary...

S

On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortner <[hidden email]> wrote:

> -1
>
> At the risk of playing Devils Advocate here, what's the downside to checked
> exceptions? A few extra lines of code?  I can foresee a problem with
> unchecked exceptions though.  Imagine that you're using the API to build a
> desktop application.  You want to display a dialog box to the user
> indicating that some problem has occurred.  With an unchecked exception,
> the
> stack trace and exception message may appear in a log file or in the
> console, but the user would in all likelihood never see it.
>
> Moreover if a developer is unfamiliar with the API, with a checked
> exception, they would be able to make an informed decision about how to
> handle the exception. The developer can easily trap the exception, and
> display a semi-informative dialog indicating that something has gone wrong.
>  Although the user may not be able to fix it, they would still know that a
> problem occurred, and would hopefully be able to file a bug report to that
> effect. If you don't want the user informed, you can always swallow the
> exception. But at least, as a developer, you have a choice about how to
> deal
> with it, and it's not something that just pops up out of no where and
> surprises both user and developer.
>
> Mark
>
> card.ly: <http://card.ly/phidias51>
>
>
> On Mon, Oct 25, 2010 at 9:01 AM, James Carman <[hidden email]
> >wrote:
>
> > On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
> > <[hidden email]> wrote:
> > > I'm not in favor of changing much at this point. I'd really like to get
> a
> > release done without too many more changes.
> > >
> >
> > There's a problem with that, Ralph.  If we publish a 2.0, we can't
> > "break" the API later.  So, we'd have to go to 3.0 if we wanted to
> > break anything.  So, we need to figure out if this is the way we want
> > to go and do it.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

James Carman
In reply to this post by Mark Fortner-3
On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortner <[hidden email]> wrote:

> -1
>
> At the risk of playing Devils Advocate here, what's the downside to checked
> exceptions? A few extra lines of code?  I can foresee a problem with
> unchecked exceptions though.  Imagine that you're using the API to build a
> desktop application.  You want to display a dialog box to the user
> indicating that some problem has occurred.  With an unchecked exception, the
> stack trace and exception message may appear in a log file or in the
> console, but the user would in all likelihood never see it.
>

It's not a few extra lines of code.  It's a few extra lines of code
everywhere you call the API (like asking if a file exists for
example).  That gets old really quickly.  For cases where you want to
display a message to the user that says "something bad happened, my
bad", then you would probably want to use a custom uncaughtException()
method on your thread groups.  Also, you can always choose to catch
unchecked exceptions if you want.  Nothing is stopping you.  You're
just not forced to do it.

> Moreover if a developer is unfamiliar with the API, with a checked
> exception, they would be able to make an informed decision about how to
> handle the exception. The developer can easily trap the exception, and
> display a semi-informative dialog indicating that something has gone wrong.
>  Although the user may not be able to fix it, they would still know that a
> problem occurred, and would hopefully be able to file a bug report to that
> effect. If you don't want the user informed, you can always swallow the
> exception. But at least, as a developer, you have a choice about how to deal
> with it, and it's not something that just pops up out of no where and
> surprises both user and developer.
>

What do people typically do with those exceptions?  Seriously, do you
retry stuff on a regular basis in your catch blocks?  I would say that
it's pretty rare that folks actually do something locally meaningful
when a checked exception occurs.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Filip Defoort
Very much -1 on unchecked exceptions.

On Mon, Oct 25, 2010 at 10:33 AM, James Carman
<[hidden email]> wrote:
>
> What do people typically do with those exceptions?  Seriously, do you
> retry stuff on a regular basis in your catch blocks?

Yes! Very much so. It's quite useful when dealing with stale nfs,
locked files,...

> I would say that
> it's pretty rare that folks actually do something locally meaningful
> when a checked exception occurs.
>

Maybe I'm the exception, but I'd be really sad to see the proper
exceptions go. I do very much agree with one of the other posters that
they could be more specific so you can easier throw groups of them
under the rug should you wish to.

- Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

James Carman
On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
<[hidden email]> wrote:
>
> Yes! Very much so. It's quite useful when dealing with stale nfs,
> locked files,...
>

Do you implement the retry logic in every place where you need it or
do you have a helper method that takes some sort of functor and it
wraps it in the try/catch/retry logic?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

James Carman
In reply to this post by Steve Siebert
On Mon, Oct 25, 2010 at 1:17 PM, Steven Siebert <[hidden email]> wrote:
> I agree with Mark's point about unfamiliar developers benefiting from
> checked exceptions.  Unlike James, I like checked exceptions =), and I have
> established "elegant" recoveries from various resource exceptions (IO, for
> example) under many use cases (at least in the enterprise arena).
>

Sure, a newbie might enjoy the warm fuzziness they feel when they know
what type of exception they have to catch when they call a certain
method.  However, that newbie, when they get familiar with said API,
will start writing work-arounds so they don't have to have all those
pesky catch blocks in their code.  They will quickly realize that
typically there isn't a darn thing they can really do when this type
of exception occurs.  Mostly, the exceptions are best handled up the
call stack by some "global" means.  So, in order to do that, you
either have to allow all your methods to throw the exception or
"tunnel" the exception up the call stack by wrapping it in a runtime
exception and throwing that.  Even if there is a retry/recovery
option, you'd use some utility method to do that, so you'd only have
the try/catch in one place as opposed to everywhere.

> What's everyones opinion on more "descriptive" Exception typing to allow me
> to handle specific failures easier (without additional testing)?  I can
> probably go through my code and find some examples if necessary...
>

I like the idea of a more descriptive hierarchy of exceptions.
Exception classes are cheap, really.  Hibernate does this (optimistic
locking exception comes to mind) and it seems to work pretty well.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Filip Defoort
In reply to this post by James Carman
On Mon, Oct 25, 2010 at 10:45 AM, James Carman
<[hidden email]> wrote:

> On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
> <[hidden email]> wrote:
>>
>> Yes! Very much so. It's quite useful when dealing with stale nfs,
>> locked files,...
>>
>
> Do you implement the retry logic in every place where you need it or
> do you have a helper method that takes some sort of functor and it
> wraps it in the try/catch/retry logic?
>

Depends. I do have a bunch of wrappers for common types of retries,
but often the remedy really is different depending on the operation
(I'm dealing a lot with search indexes, updating them and transaction
locking).

- Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Paul Benedict
Checked exceptions throw a burden onto the developer. He is forced to
do something. Why force this burden? It assumes something SHOULD be
done for these particular errors. I don't think that's realistic
(they're OS errors -- not business errors), which is why checked
exceptions have fallen well out of favor in the last decade.

On Mon, Oct 25, 2010 at 12:48 PM, Filip Defoort
<[hidden email]> wrote:

> On Mon, Oct 25, 2010 at 10:45 AM, James Carman
> <[hidden email]> wrote:
>> On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
>> <[hidden email]> wrote:
>>>
>>> Yes! Very much so. It's quite useful when dealing with stale nfs,
>>> locked files,...
>>>
>>
>> Do you implement the retry logic in every place where you need it or
>> do you have a helper method that takes some sort of functor and it
>> wraps it in the try/catch/retry logic?
>>
>
> Depends. I do have a bunch of wrappers for common types of retries,
> but often the remedy really is different depending on the operation
> (I'm dealing a lot with search indexes, updating them and transaction
> locking).
>
> - Filip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

James Carman
In reply to this post by Filip Defoort
On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort
<[hidden email]> wrote:
>
> Depends. I do have a bunch of wrappers for common types of retries,
> but often the remedy really is different depending on the operation
> (I'm dealing a lot with search indexes, updating them and transaction
> locking).
>

Again, you can use try/catch if you want to with runtime exceptions.
I'd say your usage is not typical.  Most folks don't do anything
meaningful at the local level (in the immediate catch block).  They
let the exception go up the call stack or take care of it by other
means (aspects, thread group's unchecked exception, etc).

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Filip Defoort
In reply to this post by Paul Benedict
On Mon, Oct 25, 2010 at 10:51 AM, Paul Benedict <[hidden email]> wrote:
> Checked exceptions throw a burden onto the developer. He is forced to
> do something. Why force this burden? It assumes something SHOULD be
> done for these particular errors. I don't think that's realistic
> (they're OS errors -- not business errors), which is why checked
> exceptions have fallen well out of favor in the last decade.
>

In my view, it is the developer's job to provide an solid experience
to the user. That includes properly dealing with underlying system
errors in the least cryptic possible way and recovering where
possible. And those errors aren't always OS errors - could very well
be incorrect usage/...

I do agree that that is extra work, but if you just sweep exceptions
under the rug all the time, you end up with really crappy software.

- Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Softening the exceptions...

Filip Defoort
In reply to this post by James Carman
On Mon, Oct 25, 2010 at 10:52 AM, James Carman
<[hidden email]> wrote:

> On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort
> <[hidden email]> wrote:
>>
>> Depends. I do have a bunch of wrappers for common types of retries,
>> but often the remedy really is different depending on the operation
>> (I'm dealing a lot with search indexes, updating them and transaction
>> locking).
>>
>
> Again, you can use try/catch if you want to with runtime exceptions.

No, you can't. Yes you can catch them, but you really want to start
parsing the text of the exception just to know what situation you're
in ? I already have to do that with some of the exceptions in the
mysql driver and it's a royal PITA.

> I'd say your usage is not typical.  Most folks don't do anything
> meaningful at the local level (in the immediate catch block).  They
> let the exception go up the call stack or take care of it by other
> means (aspects, thread group's unchecked exception, etc).

Typical or not, at least in my immediate work environment I know quite
a few people that deal with the same problems.

- Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12