Can I use try-with-resources with an InputStream that has already been created?
up vote
4
down vote
favorite
Like this:
public void myMethod(InputStream fileIn){
try (InputStream in = fileIn) {
do stuff....
}
}
It seems to work. Is it safe?
java inputstream try-with-resources
edited Nov 20 at 13:22
Lii
6,81144158
asked Nov 20 at 12:26
bot_bot
1,11121540
add a comment |
up vote
4
down vote
favorite
Like this:
public void myMethod(InputStream fileIn){
try (InputStream in = fileIn) {
do stuff....
}
}
It seems to work. Is it safe?
java inputstream try-with-resources
edited Nov 20 at 13:22
Lii
6,81144158
asked Nov 20 at 12:26
bot_bot
1,11121540
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
Like this:
public void myMethod(InputStream fileIn){
try (InputStream in = fileIn) {
do stuff....
}
}
It seems to work. Is it safe?
java inputstream try-with-resources
edited Nov 20 at 13:22
Lii
6,81144158
asked Nov 20 at 12:26
bot_bot
1,11121540
Like this:
public void myMethod(InputStream fileIn){
try (InputStream in = fileIn) {
do stuff....
}
}
It seems to work. Is it safe?
java inputstream try-with-resources
java inputstream try-with-resources
edited Nov 20 at 13:22
Lii
6,81144158
asked Nov 20 at 12:26
bot_bot
1,11121540
edited Nov 20 at 13:22
Lii
6,81144158
asked Nov 20 at 12:26
bot_bot
1,11121540
edited Nov 20 at 13:22
Lii
6,81144158
edited Nov 20 at 13:22
Lii
6,81144158
edited Nov 20 at 13:22
Lii
6,81144158
6,81144158
asked Nov 20 at 12:26
bot_bot
1,11121540
asked Nov 20 at 12:26
bot_bot
1,11121540
asked Nov 20 at 12:26
bot_bot
1,11121540
1,11121540
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
12
down vote
accepted
It seems to work
It will do if you add InputStream (or some supertype of InputStream) before in: the language spec requires you either to declare a variable for each resource.
try (InputStream in = fileIn) { ... }
or just refer directly to fileIn, in Java 9+:
try (fileIn) { ... }
And there's no reason why it shouldn't work: with the variable declaration form, you are assigning an expression to the variable (a new class, the result of a method invocation, an array element etc). The resource can't see if it is getting a "new" instance or not: it's just a thing with a value of the correct type.
is it safe?
Depends what exactly you mean by "safe".
It is certainly safe in the sense that it will work without error in this code, and in.close() will be invoked at the end of the block.
However, it violates the rule of thumb that "if you didn't open a stream, don't close it". As such, it might be unsafe in the sense that it causes unexpected failures in other parts of the program that expect the stream still to be open after invoking the method.
answered Nov 20 at 12:31
Andy Turner
79.4k878132
Thanks! Yeah, that was a typo on my part, I do havetry(InputStream in = fileIn)
– bot_bot
Nov 20 at 13:00
I've fixed the question
– bot_bot
Nov 20 at 13:00
Maybe I'll need to rethink my strategy in terms of opening/closing streams then. Thanks again!
– bot_bot
Nov 20 at 13:02
1
It is just a rule-of-thumb; there is nothing to say that you need to follow it. The slightly more general form is "if you don't own a stream, don't close it"; but Java has no notion of ownership of a reference, so you have to manage this yourself. If you intend formyMethodto "take ownership" of the stream, it is fine to close it here.
– Andy Turner
Nov 20 at 13:03
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53392971%2fcan-i-use-try-with-resources-with-an-inputstream-that-has-already-been-created%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
12
down vote
accepted
It seems to work
It will do if you add InputStream (or some supertype of InputStream) before in: the language spec requires you either to declare a variable for each resource.
try (InputStream in = fileIn) { ... }
or just refer directly to fileIn, in Java 9+:
try (fileIn) { ... }
And there's no reason why it shouldn't work: with the variable declaration form, you are assigning an expression to the variable (a new class, the result of a method invocation, an array element etc). The resource can't see if it is getting a "new" instance or not: it's just a thing with a value of the correct type.
is it safe?
Depends what exactly you mean by "safe".
It is certainly safe in the sense that it will work without error in this code, and in.close() will be invoked at the end of the block.
However, it violates the rule of thumb that "if you didn't open a stream, don't close it". As such, it might be unsafe in the sense that it causes unexpected failures in other parts of the program that expect the stream still to be open after invoking the method.
answered Nov 20 at 12:31
Andy Turner
79.4k878132
Thanks! Yeah, that was a typo on my part, I do havetry(InputStream in = fileIn)
– bot_bot
Nov 20 at 13:00
I've fixed the question
– bot_bot
Nov 20 at 13:00
Maybe I'll need to rethink my strategy in terms of opening/closing streams then. Thanks again!
– bot_bot
Nov 20 at 13:02
1
It is just a rule-of-thumb; there is nothing to say that you need to follow it. The slightly more general form is "if you don't own a stream, don't close it"; but Java has no notion of ownership of a reference, so you have to manage this yourself. If you intend formyMethodto "take ownership" of the stream, it is fine to close it here.
– Andy Turner
Nov 20 at 13:03
add a comment |
up vote
12
down vote
accepted
It seems to work
It will do if you add InputStream (or some supertype of InputStream) before in: the language spec requires you either to declare a variable for each resource.
try (InputStream in = fileIn) { ... }
or just refer directly to fileIn, in Java 9+:
try (fileIn) { ... }
And there's no reason why it shouldn't work: with the variable declaration form, you are assigning an expression to the variable (a new class, the result of a method invocation, an array element etc). The resource can't see if it is getting a "new" instance or not: it's just a thing with a value of the correct type.
is it safe?
Depends what exactly you mean by "safe".
It is certainly safe in the sense that it will work without error in this code, and in.close() will be invoked at the end of the block.
However, it violates the rule of thumb that "if you didn't open a stream, don't close it". As such, it might be unsafe in the sense that it causes unexpected failures in other parts of the program that expect the stream still to be open after invoking the method.
answered Nov 20 at 12:31
Andy Turner
79.4k878132
Thanks! Yeah, that was a typo on my part, I do havetry(InputStream in = fileIn)
– bot_bot
Nov 20 at 13:00
I've fixed the question
– bot_bot
Nov 20 at 13:00
Maybe I'll need to rethink my strategy in terms of opening/closing streams then. Thanks again!
– bot_bot
Nov 20 at 13:02
1
It is just a rule-of-thumb; there is nothing to say that you need to follow it. The slightly more general form is "if you don't own a stream, don't close it"; but Java has no notion of ownership of a reference, so you have to manage this yourself. If you intend formyMethodto "take ownership" of the stream, it is fine to close it here.
– Andy Turner
Nov 20 at 13:03
add a comment |
up vote
12
down vote
accepted
up vote
12
down vote
accepted
It seems to work
It will do if you add InputStream (or some supertype of InputStream) before in: the language spec requires you either to declare a variable for each resource.
try (InputStream in = fileIn) { ... }
or just refer directly to fileIn, in Java 9+:
try (fileIn) { ... }
And there's no reason why it shouldn't work: with the variable declaration form, you are assigning an expression to the variable (a new class, the result of a method invocation, an array element etc). The resource can't see if it is getting a "new" instance or not: it's just a thing with a value of the correct type.
is it safe?
Depends what exactly you mean by "safe".
It is certainly safe in the sense that it will work without error in this code, and in.close() will be invoked at the end of the block.
However, it violates the rule of thumb that "if you didn't open a stream, don't close it". As such, it might be unsafe in the sense that it causes unexpected failures in other parts of the program that expect the stream still to be open after invoking the method.
answered Nov 20 at 12:31
Andy Turner
79.4k878132
It seems to work
It will do if you add InputStream (or some supertype of InputStream) before in: the language spec requires you either to declare a variable for each resource.
try (InputStream in = fileIn) { ... }
or just refer directly to fileIn, in Java 9+:
try (fileIn) { ... }
And there's no reason why it shouldn't work: with the variable declaration form, you are assigning an expression to the variable (a new class, the result of a method invocation, an array element etc). The resource can't see if it is getting a "new" instance or not: it's just a thing with a value of the correct type.
is it safe?
Depends what exactly you mean by "safe".
It is certainly safe in the sense that it will work without error in this code, and in.close() will be invoked at the end of the block.
However, it violates the rule of thumb that "if you didn't open a stream, don't close it". As such, it might be unsafe in the sense that it causes unexpected failures in other parts of the program that expect the stream still to be open after invoking the method.
answered Nov 20 at 12:31
Andy Turner
79.4k878132
edited Nov 20 at 17:21
answered Nov 20 at 12:31
Andy Turner
79.4k878132
answered Nov 20 at 12:31
Andy Turner
79.4k878132
answered Nov 20 at 12:31
Andy Turner
79.4k878132
79.4k878132
Thanks! Yeah, that was a typo on my part, I do havetry(InputStream in = fileIn)
– bot_bot
Nov 20 at 13:00
I've fixed the question
– bot_bot
Nov 20 at 13:00
Maybe I'll need to rethink my strategy in terms of opening/closing streams then. Thanks again!
– bot_bot
Nov 20 at 13:02
1
It is just a rule-of-thumb; there is nothing to say that you need to follow it. The slightly more general form is "if you don't own a stream, don't close it"; but Java has no notion of ownership of a reference, so you have to manage this yourself. If you intend formyMethodto "take ownership" of the stream, it is fine to close it here.
– Andy Turner
Nov 20 at 13:03
add a comment |
Thanks! Yeah, that was a typo on my part, I do havetry(InputStream in = fileIn)
– bot_bot
Nov 20 at 13:00
I've fixed the question
– bot_bot
Nov 20 at 13:00
Maybe I'll need to rethink my strategy in terms of opening/closing streams then. Thanks again!
– bot_bot
Nov 20 at 13:02
1
It is just a rule-of-thumb; there is nothing to say that you need to follow it. The slightly more general form is "if you don't own a stream, don't close it"; but Java has no notion of ownership of a reference, so you have to manage this yourself. If you intend formyMethodto "take ownership" of the stream, it is fine to close it here.
– Andy Turner
Nov 20 at 13:03
Thanks! Yeah, that was a typo on my part, I do have
try(InputStream in = fileIn)– bot_bot
Nov 20 at 13:00
Thanks! Yeah, that was a typo on my part, I do have
try(InputStream in = fileIn)– bot_bot
Nov 20 at 13:00
I've fixed the question
– bot_bot
Nov 20 at 13:00
I've fixed the question
– bot_bot
Nov 20 at 13:00
Maybe I'll need to rethink my strategy in terms of opening/closing streams then. Thanks again!
– bot_bot
Nov 20 at 13:02
Maybe I'll need to rethink my strategy in terms of opening/closing streams then. Thanks again!
– bot_bot
Nov 20 at 13:02
1
1
It is just a rule-of-thumb; there is nothing to say that you need to follow it. The slightly more general form is "if you don't own a stream, don't close it"; but Java has no notion of ownership of a reference, so you have to manage this yourself. If you intend for
myMethod to "take ownership" of the stream, it is fine to close it here.– Andy Turner
Nov 20 at 13:03
It is just a rule-of-thumb; there is nothing to say that you need to follow it. The slightly more general form is "if you don't own a stream, don't close it"; but Java has no notion of ownership of a reference, so you have to manage this yourself. If you intend for
myMethod to "take ownership" of the stream, it is fine to close it here.– Andy Turner
Nov 20 at 13:03
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53392971%2fcan-i-use-try-with-resources-with-an-inputstream-that-has-already-been-created%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
