C# Cancel Method via calling a Method
Hello StackOver Community,
I have the following c#-code
void foo(int x)
{
if(x<=0)
{
return;
}
do something more...
.
.
.
}
I want to get rid of the if statement by calling a function which will "return" my foo function if the condition x<= 0 is met.
That is
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
}
private ???? TerminateIfNegative(int a)
{
if (a<=0)
{
"Make the method which called me "return" at the place I was called"
}
}
I hope it is somehow clear what I want to do. Does someone have an idea?
Cheers,
Florian
c# stack-trace
|
show 1 more comment
Hello StackOver Community,
I have the following c#-code
void foo(int x)
{
if(x<=0)
{
return;
}
do something more...
.
.
.
}
I want to get rid of the if statement by calling a function which will "return" my foo function if the condition x<= 0 is met.
That is
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
}
private ???? TerminateIfNegative(int a)
{
if (a<=0)
{
"Make the method which called me "return" at the place I was called"
}
}
I hope it is somehow clear what I want to do. Does someone have an idea?
Cheers,
Florian
c# stack-trace
the function is declared void as the return method so how can you return something?
– jdweng
Nov 23 '18 at 14:33
Why do you want to do this? Is not return clear enough as a way to exit and terminate your code?
– Steve
Nov 23 '18 at 14:33
"I want to get rid of the if statement" Why? Seems pretty clear to me. Any different approach will make it less readable.
– HimBromBeere
Nov 23 '18 at 14:33
@jdweng I assume OP doesn´t want to return something, just exit the parent method.
– HimBromBeere
Nov 23 '18 at 14:33
2
The only practical way to "terminate" a method, other than with an if-statement that skips a bunch of code, is by throwing an exception. Maybe not appropriate here, but exceptional conditions ought to have exceptional behavior. The caller tends to need to know that a thing it asked to happen did not actually happen.
– Hans Passant
Nov 23 '18 at 14:34
|
show 1 more comment
Hello StackOver Community,
I have the following c#-code
void foo(int x)
{
if(x<=0)
{
return;
}
do something more...
.
.
.
}
I want to get rid of the if statement by calling a function which will "return" my foo function if the condition x<= 0 is met.
That is
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
}
private ???? TerminateIfNegative(int a)
{
if (a<=0)
{
"Make the method which called me "return" at the place I was called"
}
}
I hope it is somehow clear what I want to do. Does someone have an idea?
Cheers,
Florian
c# stack-trace
Hello StackOver Community,
I have the following c#-code
void foo(int x)
{
if(x<=0)
{
return;
}
do something more...
.
.
.
}
I want to get rid of the if statement by calling a function which will "return" my foo function if the condition x<= 0 is met.
That is
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
}
private ???? TerminateIfNegative(int a)
{
if (a<=0)
{
"Make the method which called me "return" at the place I was called"
}
}
I hope it is somehow clear what I want to do. Does someone have an idea?
Cheers,
Florian
c# stack-trace
c# stack-trace
edited Nov 23 '18 at 14:35
Florian Speicher
asked Nov 23 '18 at 14:30
Florian SpeicherFlorian Speicher
11
11
the function is declared void as the return method so how can you return something?
– jdweng
Nov 23 '18 at 14:33
Why do you want to do this? Is not return clear enough as a way to exit and terminate your code?
– Steve
Nov 23 '18 at 14:33
"I want to get rid of the if statement" Why? Seems pretty clear to me. Any different approach will make it less readable.
– HimBromBeere
Nov 23 '18 at 14:33
@jdweng I assume OP doesn´t want to return something, just exit the parent method.
– HimBromBeere
Nov 23 '18 at 14:33
2
The only practical way to "terminate" a method, other than with an if-statement that skips a bunch of code, is by throwing an exception. Maybe not appropriate here, but exceptional conditions ought to have exceptional behavior. The caller tends to need to know that a thing it asked to happen did not actually happen.
– Hans Passant
Nov 23 '18 at 14:34
|
show 1 more comment
the function is declared void as the return method so how can you return something?
– jdweng
Nov 23 '18 at 14:33
Why do you want to do this? Is not return clear enough as a way to exit and terminate your code?
– Steve
Nov 23 '18 at 14:33
"I want to get rid of the if statement" Why? Seems pretty clear to me. Any different approach will make it less readable.
– HimBromBeere
Nov 23 '18 at 14:33
@jdweng I assume OP doesn´t want to return something, just exit the parent method.
– HimBromBeere
Nov 23 '18 at 14:33
2
The only practical way to "terminate" a method, other than with an if-statement that skips a bunch of code, is by throwing an exception. Maybe not appropriate here, but exceptional conditions ought to have exceptional behavior. The caller tends to need to know that a thing it asked to happen did not actually happen.
– Hans Passant
Nov 23 '18 at 14:34
the function is declared void as the return method so how can you return something?
– jdweng
Nov 23 '18 at 14:33
the function is declared void as the return method so how can you return something?
– jdweng
Nov 23 '18 at 14:33
Why do you want to do this? Is not return clear enough as a way to exit and terminate your code?
– Steve
Nov 23 '18 at 14:33
Why do you want to do this? Is not return clear enough as a way to exit and terminate your code?
– Steve
Nov 23 '18 at 14:33
"I want to get rid of the if statement" Why? Seems pretty clear to me. Any different approach will make it less readable.
– HimBromBeere
Nov 23 '18 at 14:33
"I want to get rid of the if statement" Why? Seems pretty clear to me. Any different approach will make it less readable.
– HimBromBeere
Nov 23 '18 at 14:33
@jdweng I assume OP doesn´t want to return something, just exit the parent method.
– HimBromBeere
Nov 23 '18 at 14:33
@jdweng I assume OP doesn´t want to return something, just exit the parent method.
– HimBromBeere
Nov 23 '18 at 14:33
2
2
The only practical way to "terminate" a method, other than with an if-statement that skips a bunch of code, is by throwing an exception. Maybe not appropriate here, but exceptional conditions ought to have exceptional behavior. The caller tends to need to know that a thing it asked to happen did not actually happen.
– Hans Passant
Nov 23 '18 at 14:34
The only practical way to "terminate" a method, other than with an if-statement that skips a bunch of code, is by throwing an exception. Maybe not appropriate here, but exceptional conditions ought to have exceptional behavior. The caller tends to need to know that a thing it asked to happen did not actually happen.
– Hans Passant
Nov 23 '18 at 14:34
|
show 1 more comment
4 Answers
4
active
oldest
votes
When a method's return type is void
, this method does not return anything. There are only the following options to stop the execution of commands inside a void method:
- Throw an exception
- Use
return;
(which is the most common way)
If a negative value should not be passed as an argument to your method, then it is valid to throw an exception and document that, in order callers of this method to be aware of this from the very beggining.
add a comment |
The behaviour you´re asking for is common in procedural programming where you have a common linear program-flow from the very first line to the very last. This will apply to a line-by-line execution, which isn´t what OOP is about. There are good reasons we usually discourage use of goto
and other stuff that controls program-flow as it will make it very hard to follow your code, e.g. when debugging. In fact this leads to spaghetti-code.
Imagine you want to debug your app in a few months. You step through your code until you reach Foo
, step into it to sea what it does and - woaah, what is this - your debuger jumps out of Foo
for whatever reason. It´s completely unclear why the method simply stops its execution.
What you seem to want actually is performing some checks on your user-input. So if your user types in a negative number your program should stop. It´s pure fine to throw an exception in this case, which basically indicates that a method cannot do what it is supposed to do. You could just create some Validate
-method that throws an exception on ivalid input:
void Validate(int x)
{
if(x <= 0)
throw new InvalidArgumentException("x must not be negative");
}
This leaves it to the caller of the method how to handle an error. This way your Validate
-method just validates the input. It should not terminate the calling method, which would break the single-responsibility-principle, wouldn´t it?
However throwing an exception in your case seems a bit like taking a a sledgehammer to crack a nut. The most simple and cleanest way is to do exactly what you want to avoid. Have an if-statement that terminates foo
if the input is invalid:
void foo()
{
if(!Validate(x))
return;
}
bool Validate(int x)
{
return x > 0;
}
add a comment |
Do you mean the following:
void foo(int x)
{
if(!TerminateIfNegative(x))
{
do something more...
.
.
.
}
}
private bool TerminateIfNegative(int a)
{
bool result = false;
if (a < 0)
{
result = true;
}
return result;
}
add a comment |
Actually there is a solution for this. And a pretty ugly one.
I'm aware that probably nobody will agree that this should be used, but I will present it anyway. Here you have the infamous goto solution:
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
EndOfFoo:
}
private void TerminateIfNegative(int a)
{
if (a<=0)
{
goto EndOfFoo;
}
}
2
Have you tried compiling this? You cannot goto a label that is outside the scope of the method.
– PaulF
Nov 23 '18 at 15:01
The goto is something I dont really suggest to use. Also as per above comment , you are outside the scope and most probably wont work.
– Alex Leo
Nov 23 '18 at 19:31
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',
autoActivateHeartbeat: false,
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%2f53448539%2fc-sharp-cancel-method-via-calling-a-method%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
When a method's return type is void
, this method does not return anything. There are only the following options to stop the execution of commands inside a void method:
- Throw an exception
- Use
return;
(which is the most common way)
If a negative value should not be passed as an argument to your method, then it is valid to throw an exception and document that, in order callers of this method to be aware of this from the very beggining.
add a comment |
When a method's return type is void
, this method does not return anything. There are only the following options to stop the execution of commands inside a void method:
- Throw an exception
- Use
return;
(which is the most common way)
If a negative value should not be passed as an argument to your method, then it is valid to throw an exception and document that, in order callers of this method to be aware of this from the very beggining.
add a comment |
When a method's return type is void
, this method does not return anything. There are only the following options to stop the execution of commands inside a void method:
- Throw an exception
- Use
return;
(which is the most common way)
If a negative value should not be passed as an argument to your method, then it is valid to throw an exception and document that, in order callers of this method to be aware of this from the very beggining.
When a method's return type is void
, this method does not return anything. There are only the following options to stop the execution of commands inside a void method:
- Throw an exception
- Use
return;
(which is the most common way)
If a negative value should not be passed as an argument to your method, then it is valid to throw an exception and document that, in order callers of this method to be aware of this from the very beggining.
edited Nov 23 '18 at 14:36
answered Nov 23 '18 at 14:35
ChristosChristos
43.6k84476
43.6k84476
add a comment |
add a comment |
The behaviour you´re asking for is common in procedural programming where you have a common linear program-flow from the very first line to the very last. This will apply to a line-by-line execution, which isn´t what OOP is about. There are good reasons we usually discourage use of goto
and other stuff that controls program-flow as it will make it very hard to follow your code, e.g. when debugging. In fact this leads to spaghetti-code.
Imagine you want to debug your app in a few months. You step through your code until you reach Foo
, step into it to sea what it does and - woaah, what is this - your debuger jumps out of Foo
for whatever reason. It´s completely unclear why the method simply stops its execution.
What you seem to want actually is performing some checks on your user-input. So if your user types in a negative number your program should stop. It´s pure fine to throw an exception in this case, which basically indicates that a method cannot do what it is supposed to do. You could just create some Validate
-method that throws an exception on ivalid input:
void Validate(int x)
{
if(x <= 0)
throw new InvalidArgumentException("x must not be negative");
}
This leaves it to the caller of the method how to handle an error. This way your Validate
-method just validates the input. It should not terminate the calling method, which would break the single-responsibility-principle, wouldn´t it?
However throwing an exception in your case seems a bit like taking a a sledgehammer to crack a nut. The most simple and cleanest way is to do exactly what you want to avoid. Have an if-statement that terminates foo
if the input is invalid:
void foo()
{
if(!Validate(x))
return;
}
bool Validate(int x)
{
return x > 0;
}
add a comment |
The behaviour you´re asking for is common in procedural programming where you have a common linear program-flow from the very first line to the very last. This will apply to a line-by-line execution, which isn´t what OOP is about. There are good reasons we usually discourage use of goto
and other stuff that controls program-flow as it will make it very hard to follow your code, e.g. when debugging. In fact this leads to spaghetti-code.
Imagine you want to debug your app in a few months. You step through your code until you reach Foo
, step into it to sea what it does and - woaah, what is this - your debuger jumps out of Foo
for whatever reason. It´s completely unclear why the method simply stops its execution.
What you seem to want actually is performing some checks on your user-input. So if your user types in a negative number your program should stop. It´s pure fine to throw an exception in this case, which basically indicates that a method cannot do what it is supposed to do. You could just create some Validate
-method that throws an exception on ivalid input:
void Validate(int x)
{
if(x <= 0)
throw new InvalidArgumentException("x must not be negative");
}
This leaves it to the caller of the method how to handle an error. This way your Validate
-method just validates the input. It should not terminate the calling method, which would break the single-responsibility-principle, wouldn´t it?
However throwing an exception in your case seems a bit like taking a a sledgehammer to crack a nut. The most simple and cleanest way is to do exactly what you want to avoid. Have an if-statement that terminates foo
if the input is invalid:
void foo()
{
if(!Validate(x))
return;
}
bool Validate(int x)
{
return x > 0;
}
add a comment |
The behaviour you´re asking for is common in procedural programming where you have a common linear program-flow from the very first line to the very last. This will apply to a line-by-line execution, which isn´t what OOP is about. There are good reasons we usually discourage use of goto
and other stuff that controls program-flow as it will make it very hard to follow your code, e.g. when debugging. In fact this leads to spaghetti-code.
Imagine you want to debug your app in a few months. You step through your code until you reach Foo
, step into it to sea what it does and - woaah, what is this - your debuger jumps out of Foo
for whatever reason. It´s completely unclear why the method simply stops its execution.
What you seem to want actually is performing some checks on your user-input. So if your user types in a negative number your program should stop. It´s pure fine to throw an exception in this case, which basically indicates that a method cannot do what it is supposed to do. You could just create some Validate
-method that throws an exception on ivalid input:
void Validate(int x)
{
if(x <= 0)
throw new InvalidArgumentException("x must not be negative");
}
This leaves it to the caller of the method how to handle an error. This way your Validate
-method just validates the input. It should not terminate the calling method, which would break the single-responsibility-principle, wouldn´t it?
However throwing an exception in your case seems a bit like taking a a sledgehammer to crack a nut. The most simple and cleanest way is to do exactly what you want to avoid. Have an if-statement that terminates foo
if the input is invalid:
void foo()
{
if(!Validate(x))
return;
}
bool Validate(int x)
{
return x > 0;
}
The behaviour you´re asking for is common in procedural programming where you have a common linear program-flow from the very first line to the very last. This will apply to a line-by-line execution, which isn´t what OOP is about. There are good reasons we usually discourage use of goto
and other stuff that controls program-flow as it will make it very hard to follow your code, e.g. when debugging. In fact this leads to spaghetti-code.
Imagine you want to debug your app in a few months. You step through your code until you reach Foo
, step into it to sea what it does and - woaah, what is this - your debuger jumps out of Foo
for whatever reason. It´s completely unclear why the method simply stops its execution.
What you seem to want actually is performing some checks on your user-input. So if your user types in a negative number your program should stop. It´s pure fine to throw an exception in this case, which basically indicates that a method cannot do what it is supposed to do. You could just create some Validate
-method that throws an exception on ivalid input:
void Validate(int x)
{
if(x <= 0)
throw new InvalidArgumentException("x must not be negative");
}
This leaves it to the caller of the method how to handle an error. This way your Validate
-method just validates the input. It should not terminate the calling method, which would break the single-responsibility-principle, wouldn´t it?
However throwing an exception in your case seems a bit like taking a a sledgehammer to crack a nut. The most simple and cleanest way is to do exactly what you want to avoid. Have an if-statement that terminates foo
if the input is invalid:
void foo()
{
if(!Validate(x))
return;
}
bool Validate(int x)
{
return x > 0;
}
edited Nov 23 '18 at 14:59
answered Nov 23 '18 at 14:53
HimBromBeereHimBromBeere
23.3k43159
23.3k43159
add a comment |
add a comment |
Do you mean the following:
void foo(int x)
{
if(!TerminateIfNegative(x))
{
do something more...
.
.
.
}
}
private bool TerminateIfNegative(int a)
{
bool result = false;
if (a < 0)
{
result = true;
}
return result;
}
add a comment |
Do you mean the following:
void foo(int x)
{
if(!TerminateIfNegative(x))
{
do something more...
.
.
.
}
}
private bool TerminateIfNegative(int a)
{
bool result = false;
if (a < 0)
{
result = true;
}
return result;
}
add a comment |
Do you mean the following:
void foo(int x)
{
if(!TerminateIfNegative(x))
{
do something more...
.
.
.
}
}
private bool TerminateIfNegative(int a)
{
bool result = false;
if (a < 0)
{
result = true;
}
return result;
}
Do you mean the following:
void foo(int x)
{
if(!TerminateIfNegative(x))
{
do something more...
.
.
.
}
}
private bool TerminateIfNegative(int a)
{
bool result = false;
if (a < 0)
{
result = true;
}
return result;
}
answered Nov 23 '18 at 19:27
Alex LeoAlex Leo
461211
461211
add a comment |
add a comment |
Actually there is a solution for this. And a pretty ugly one.
I'm aware that probably nobody will agree that this should be used, but I will present it anyway. Here you have the infamous goto solution:
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
EndOfFoo:
}
private void TerminateIfNegative(int a)
{
if (a<=0)
{
goto EndOfFoo;
}
}
2
Have you tried compiling this? You cannot goto a label that is outside the scope of the method.
– PaulF
Nov 23 '18 at 15:01
The goto is something I dont really suggest to use. Also as per above comment , you are outside the scope and most probably wont work.
– Alex Leo
Nov 23 '18 at 19:31
add a comment |
Actually there is a solution for this. And a pretty ugly one.
I'm aware that probably nobody will agree that this should be used, but I will present it anyway. Here you have the infamous goto solution:
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
EndOfFoo:
}
private void TerminateIfNegative(int a)
{
if (a<=0)
{
goto EndOfFoo;
}
}
2
Have you tried compiling this? You cannot goto a label that is outside the scope of the method.
– PaulF
Nov 23 '18 at 15:01
The goto is something I dont really suggest to use. Also as per above comment , you are outside the scope and most probably wont work.
– Alex Leo
Nov 23 '18 at 19:31
add a comment |
Actually there is a solution for this. And a pretty ugly one.
I'm aware that probably nobody will agree that this should be used, but I will present it anyway. Here you have the infamous goto solution:
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
EndOfFoo:
}
private void TerminateIfNegative(int a)
{
if (a<=0)
{
goto EndOfFoo;
}
}
Actually there is a solution for this. And a pretty ugly one.
I'm aware that probably nobody will agree that this should be used, but I will present it anyway. Here you have the infamous goto solution:
void foo(int x)
{
TerminateIfNegative(x);
do something more...
.
.
.
EndOfFoo:
}
private void TerminateIfNegative(int a)
{
if (a<=0)
{
goto EndOfFoo;
}
}
answered Nov 23 '18 at 14:48
NicoNico
455
455
2
Have you tried compiling this? You cannot goto a label that is outside the scope of the method.
– PaulF
Nov 23 '18 at 15:01
The goto is something I dont really suggest to use. Also as per above comment , you are outside the scope and most probably wont work.
– Alex Leo
Nov 23 '18 at 19:31
add a comment |
2
Have you tried compiling this? You cannot goto a label that is outside the scope of the method.
– PaulF
Nov 23 '18 at 15:01
The goto is something I dont really suggest to use. Also as per above comment , you are outside the scope and most probably wont work.
– Alex Leo
Nov 23 '18 at 19:31
2
2
Have you tried compiling this? You cannot goto a label that is outside the scope of the method.
– PaulF
Nov 23 '18 at 15:01
Have you tried compiling this? You cannot goto a label that is outside the scope of the method.
– PaulF
Nov 23 '18 at 15:01
The goto is something I dont really suggest to use. Also as per above comment , you are outside the scope and most probably wont work.
– Alex Leo
Nov 23 '18 at 19:31
The goto is something I dont really suggest to use. Also as per above comment , you are outside the scope and most probably wont work.
– Alex Leo
Nov 23 '18 at 19:31
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.
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%2f53448539%2fc-sharp-cancel-method-via-calling-a-method%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
the function is declared void as the return method so how can you return something?
– jdweng
Nov 23 '18 at 14:33
Why do you want to do this? Is not return clear enough as a way to exit and terminate your code?
– Steve
Nov 23 '18 at 14:33
"I want to get rid of the if statement" Why? Seems pretty clear to me. Any different approach will make it less readable.
– HimBromBeere
Nov 23 '18 at 14:33
@jdweng I assume OP doesn´t want to return something, just exit the parent method.
– HimBromBeere
Nov 23 '18 at 14:33
2
The only practical way to "terminate" a method, other than with an if-statement that skips a bunch of code, is by throwing an exception. Maybe not appropriate here, but exceptional conditions ought to have exceptional behavior. The caller tends to need to know that a thing it asked to happen did not actually happen.
– Hans Passant
Nov 23 '18 at 14:34