On Mon, Oct 25, 2010 at 7:44 PM, Ralph Goers wrote:
>
> This code has been sitting here for a year. Commons Configuration would like
> to do a release but cannot until VFS is released. I'd like to work on the VFS
> release during the hackathon next week. If you believe you can change how VFS
>
On Oct 25, 2010, at 9:01 AM, James Carman wrote:
> On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
> 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
Hi!
Am 25.10.2010 um 21:13 schrieb "James Carman" :
> On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
> wrote:
>>
>> So for VFS, you would prefer that all error handling be done with unchecked
>>
>
> In a nutshell, yes. So, it's a pretty easy change. You'd just change
> the superclass of Fil
> -Original Message-
> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
> Behalf Of James Carman
> Sent: Monday, October 25, 2010 10:33
> To: Commons Developers List
> Subject: Re: [VFS] Softening the exceptions...
>
> On Mon, Oct 25
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
wrote:
>
> So for VFS, you would prefer that all error handling be done with unchecked
> exceptions?
>
This is probably a question better asked on the user list so we can
get a feel for how people feel about it. I just wanted to start the
discussion
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
wrote:
>
> So for VFS, you would prefer that all error handling be done with unchecked
> exceptions?
>
In a nutshell, yes. So, it's a pretty easy change. You'd just change
the superclass of FileSystemException.
> -Original Message-
> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
> Behalf Of James Carman
> Sent: Monday, October 25, 2010 08:10
> To: Commons Developers List
> Subject: Re: [VFS] Softening the exceptions...
>
> On Mon, Oct 25
On Mon, Oct 25, 2010 at 2:00 PM, Filip Defoort
wrote:
> Well, it's my job to write proper code. Other people can do all they
> want, but with just a runtime exception I wouldn't be able to do what
> I'd need to do.
>
Again, I think you're misunderstanding my suggestion. I'm suggesting
to do this
On Mon, Oct 25, 2010 at 10:56 AM, James Carman
wrote:
> On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort
> wrote:
>>
>> 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
On Mon, Oct 25, 2010 at 1:55 PM, Filip Defoort
wrote:
>
> 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 P
On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort
wrote:
>
> 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 al
On Mon, Oct 25, 2010 at 10:52 AM, James Carman
wrote:
> On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort
> 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 indexe
On Mon, Oct 25, 2010 at 10:51 AM, Paul Benedict 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 busine
On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort
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
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
On Mon, Oct 25, 2010 at 10:45 AM, James Carman
wrote:
> On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
> 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 h
On Mon, Oct 25, 2010 at 1:17 PM, Steven Siebert 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
On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
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
Very much -1 on unchecked exceptions.
On Mon, Oct 25, 2010 at 10:33 AM, James Carman
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 fi
On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortner 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 a
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 ever
-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
indicati
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
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 i
+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
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 wrote:
>
> On Oct 25, 2010, at 8:10 AM, James Carman wrote:
>
> > On Mon, Oct 25, 2010 at 11:05 A
On Oct 25, 2010, at 8:10 AM, James Carman wrote:
> On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
> 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* t
On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
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 wou
ftware.com
> -Original Message-
> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] 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
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 wrote:
> +1 on this issue.
>
> I use VFS on a couple projects and this is always a bit burd
+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
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: de
31 matches
Mail list logo
