Github user jochenw commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
I agree with Garys concerns (in particular, because I know how widely
spread fileupload is, and how difficult it can be to replace the containers
version with your own), so won't change th
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
FooDiskItem.write is not part of FileUpload, so it *can* throw Exception if
it has not been recompiled since it was compiled against FileUpload 1.3.3.
---
--
Github user krichter722 commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
> I run my FooDiskFileItem that throws an Exception (not an IOException).
How? If `DiskItem.write` doesn't throw `Exception` `FooDiskItem.write`
can't.
> My new code o
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
Surely if your new code uses FooDiskFileItem, it needs to know that it
throws Exception and catch that accordingly? Why would you knowingly use
FooDiskFileItem but not catch Exception?
-
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
I am concerned about:
- I create a class or jar with a subclass of `DiskFileItem` called
`FooDiskFileItem` that throws an `Exception` against FileUpload 1.3.3.
- We release Fil
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
AFAICT this only affects source compatibility.
I was able to run the subclass (throwing Exception) against the base class
(updated to throw IOE).
Of course I could not compile
Github user krichter722 commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
> True, but what if I have a subclass of DiskFileItem that throws an
Exception? What happens at runtime?
Correct, I didn't think about that. I'm already glad, you're willing to
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
@krichter722 Yes. I meant to say: changing a throw clause can affect source
compatibility
@garydgregory - are you asking whether an overloaded method will have to be
amended?
--
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
True, but what if I have a subclass of DiskFileItem that throws an
Exception?
Note: We are OK with breaking source compatibility but not BC outside of a
major release.
--
Github user krichter722 commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
In any previous situation users needed to catch `Exception`. Since both
exception extend `Exception` there's no case where they need to change any code.
---
-
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
The throws clause is not part of the method signature, and does not affect
binary compatibility.
However it does affect source compatibilty
---
-
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
I think that would break binary compatibility. So it would have to be for
2.0.
---
-
To unsubscribe, e-mail: dev-
Github user coveralls commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
[](https://coveralls.io/builds/17079215)
Coverage remained the same at 77.177% when pulling
**77d68a7ce0d15c05
13 matches
Mail list logo
