Re: [VFS] Softening the exceptions...
+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 ja...@carmanconsulting.comwrote: 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Oct 25, 2010, at 8:10 AM, James Carman wrote: On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory ggreg...@seagullsoftware.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
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 ralph.go...@dslextreme.comwrote: On Oct 25, 2010, at 8:10 AM, James Carman wrote: On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory ggreg...@seagullsoftware.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
+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 ralph.go...@dslextreme.com wrote: On Oct 25, 2010, at 8:10 AM, James Carman wrote: On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory ggreg...@seagullsoftware.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
-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 ja...@carmanconsulting.comwrote: On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
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 phidia...@gmail.com 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 ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
Very much -1 on unchecked exceptions. On Mon, Oct 25, 2010 at 10:33 AM, James Carman ja...@carmanconsulting.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort filip...@cirquedigital.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 1:17 PM, Steven Siebert smsi...@gmail.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 10:45 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort filip...@cirquedigital.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
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 filip...@cirquedigital.com wrote: On Mon, Oct 25, 2010 at 10:45 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort filip...@cirquedigital.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort filip...@cirquedigital.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 10:51 AM, Paul Benedict pbened...@apache.org 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 10:52 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort filip...@cirquedigital.com 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort filip...@cirquedigital.com 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 always OS errors - could very well be incorrect usage/... So, fix your incorrect usage during testing. 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. That's not our job to police folks' code. If they want to write crappy software, then let them. Maybe someone will hire us to come fix it! :) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 10:56 AM, James Carman ja...@carmanconsulting.com wrote: On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort filip...@cirquedigital.com 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 always OS errors - could very well be incorrect usage/... So, fix your incorrect usage during testing. Not _my_ incorrect usage. I write multi user applications and sometimes one user does something that causes problem for another user. Due to business constraints it's not always possible to avoid letter them shoot themselves in the foot, but I still need to recover from it (lest I get all the blame for the problem). 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. That's not our job to police folks' code. If they want to write crappy software, then let them. Maybe someone will hire us to come fix it! :) 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. Just my .02$. - Filip - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 2:00 PM, Filip Defoort filip...@cirquedigital.com 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: public class FileSystemException extends RuntimeException as opposed to public class FileSystemException extends IOException This makes all VFS's exceptions unchecked. They can be caught if you want or they can be propagated up the call stack without having to wrap them up and do it yourself. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VFS] Softening the exceptions...
-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, 2010 at 11:05 AM, Gary Gregory ggreg...@seagullsoftware.com 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. So for VFS, you would prefer that all error handling be done with unchecked exceptions? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory ggreg...@seagullsoftware.com 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. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory ggreg...@seagullsoftware.com 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 here among the development team. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VFS] Softening the exceptions...
-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, 2010 at 12:49 PM, Mark Fortner phidia...@gmail.com 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. I think about this using Murphy's law: What do I want my application to do when the API throws an exception? It will, sooner than I think. While it is true that I can catch unchecked exceptions, these are /supposed/ to be programmer errors (IllegalStateException) or catastrophic (OutOfMemoryError). Checked exceptions are expected (this file is missing, the network goes down in the middle of processing, for example.) The distinction is important. Tossing checked exceptions out the window is like hiding something under the rug. You're gonna trip on it! Gary 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
Hi! Am 25.10.2010 um 21:13 schrieb James Carman ja...@carmanconsulting.com: On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory ggreg...@seagullsoftware.com 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 FileSystemException. To bring in my two 2ct. I foo think that the FileSystemException could be a runtime exception. As long as it represents a non-recoverable exception. Something which might throw things like a filenotfoundexception should be checked, still. What I would like to say is, simply changing the exception inheritance is not sufficient and for no ones help. We need to work out a concept which method throws which checked or unchecked exception. As we had Hibernate in the thread, I think Hibernate has gone too far in this question and you have to be very familiar with the API to know which exception to catch when. This does not help if you are going to translate a technical exception to something meaningful for the user. The problem with VFS is that it throws mostly just a FSE without any chance to get the real cause in you program - you have to parse the message - which is bad. Ciao, Mario - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Oct 25, 2010, at 9:01 AM, James Carman wrote: On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.com 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. 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 does exception handling and then make the necessary changes (if any) to Commons Configuration so that we can work on a release next week then go for it. Will you be at ApacheCon? Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 7:44 PM, Ralph Goers ralph.go...@dslextreme.com 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 does exception handling and then make the necessary changes (if any) to Commons Configuration so that we can work on a release next week then go for it. I didn't come up with the softening exceptions idea until just today when I was coding using VFS. Our project at work uses VFS extensively. I don't mind helping, but I don't think we have a consensus about what we are going to do. We should probably figure out what the plan of attack is before we start hacking around. I really think the exceptions should be softened, because it makes working with VFS a real pain, IMHO. The only place where you'll see a problem in Configuration is where you used to use IOException as a catch-all to catch VFS exceptions too. Otherwise, you can still do try/catch with FileSystemException and those will work. You just don't have to do the try/catch. Will you be at ApacheCon? Unfortunately, I will not. We have a newborn at home, so I don't think I should try leaving the wife at home alone right now. :) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
