dotnet return 1 of 2 types [duplicate]
This question already has an answer here:
C# Return Different Types?
15 answers
I have a simple method setup to create an entry and if it's successful, return the created entry. If it wasn't return the ValidationError.
public async Task<MyNewEntry> CreateEntry(MyUser user, MyEntryRequest entry)
This works great if the entry was valid. But, I want to return the ValidationError if the validation failed.
I tried doing this:
public async Task<MyNewEntry | ValidationError> CreateEntry(MyUser user, MyEntryRequest entry)
But then it doesn't compile. How do I construct this method so that it's capable of returning either MyNewEntry or ValidationError
c# .net
marked as duplicate by Alexei Levenkov
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 25 '18 at 3:15
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
|
show 3 more comments
This question already has an answer here:
C# Return Different Types?
15 answers
I have a simple method setup to create an entry and if it's successful, return the created entry. If it wasn't return the ValidationError.
public async Task<MyNewEntry> CreateEntry(MyUser user, MyEntryRequest entry)
This works great if the entry was valid. But, I want to return the ValidationError if the validation failed.
I tried doing this:
public async Task<MyNewEntry | ValidationError> CreateEntry(MyUser user, MyEntryRequest entry)
But then it doesn't compile. How do I construct this method so that it's capable of returning either MyNewEntry or ValidationError
c# .net
marked as duplicate by Alexei Levenkov
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 25 '18 at 3:15
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
3
AFAIK there isn't anything built-in. You could wrap them in an Either structure (like Scala has), or e.g. wrap the validation error in an exception, or return one as an out param and the other one null if set, but I'm not sure any of these are super clean.
– Rup
Nov 24 '18 at 23:31
2
Returning two different types is generally a bad idea. You could simply setup a "valid" flag in your MyNewEntry class that indicates success or failure.
– Idle_Mind
Nov 24 '18 at 23:32
1
Yea, I was trying to avoid modifying the types as they are third party. I think I'll just make a wrapper class that knows how to handle it.
– mwilson
Nov 24 '18 at 23:32
Use aTuple? A parent class? Really sounds like you should be throwing an exception though. Validation fails aren’t something you can resolve in compile time
– Caius Jard
Nov 24 '18 at 23:57
1
This would be exception driven design, and given the impact that exceptions have on the application, this should be avoided under all circumstances. Avoid throwing exceptions, when you know what can happen. Validation-Result, no matter what kind, are not exceptions.
– Chris
Nov 25 '18 at 0:02
|
show 3 more comments
This question already has an answer here:
C# Return Different Types?
15 answers
I have a simple method setup to create an entry and if it's successful, return the created entry. If it wasn't return the ValidationError.
public async Task<MyNewEntry> CreateEntry(MyUser user, MyEntryRequest entry)
This works great if the entry was valid. But, I want to return the ValidationError if the validation failed.
I tried doing this:
public async Task<MyNewEntry | ValidationError> CreateEntry(MyUser user, MyEntryRequest entry)
But then it doesn't compile. How do I construct this method so that it's capable of returning either MyNewEntry or ValidationError
c# .net
This question already has an answer here:
C# Return Different Types?
15 answers
I have a simple method setup to create an entry and if it's successful, return the created entry. If it wasn't return the ValidationError.
public async Task<MyNewEntry> CreateEntry(MyUser user, MyEntryRequest entry)
This works great if the entry was valid. But, I want to return the ValidationError if the validation failed.
I tried doing this:
public async Task<MyNewEntry | ValidationError> CreateEntry(MyUser user, MyEntryRequest entry)
But then it doesn't compile. How do I construct this method so that it's capable of returning either MyNewEntry or ValidationError
This question already has an answer here:
C# Return Different Types?
15 answers
c# .net
c# .net
asked Nov 24 '18 at 23:27
mwilsonmwilson
3,15232048
3,15232048
marked as duplicate by Alexei Levenkov
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 25 '18 at 3:15
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Alexei Levenkov
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 25 '18 at 3:15
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
3
AFAIK there isn't anything built-in. You could wrap them in an Either structure (like Scala has), or e.g. wrap the validation error in an exception, or return one as an out param and the other one null if set, but I'm not sure any of these are super clean.
– Rup
Nov 24 '18 at 23:31
2
Returning two different types is generally a bad idea. You could simply setup a "valid" flag in your MyNewEntry class that indicates success or failure.
– Idle_Mind
Nov 24 '18 at 23:32
1
Yea, I was trying to avoid modifying the types as they are third party. I think I'll just make a wrapper class that knows how to handle it.
– mwilson
Nov 24 '18 at 23:32
Use aTuple? A parent class? Really sounds like you should be throwing an exception though. Validation fails aren’t something you can resolve in compile time
– Caius Jard
Nov 24 '18 at 23:57
1
This would be exception driven design, and given the impact that exceptions have on the application, this should be avoided under all circumstances. Avoid throwing exceptions, when you know what can happen. Validation-Result, no matter what kind, are not exceptions.
– Chris
Nov 25 '18 at 0:02
|
show 3 more comments
3
AFAIK there isn't anything built-in. You could wrap them in an Either structure (like Scala has), or e.g. wrap the validation error in an exception, or return one as an out param and the other one null if set, but I'm not sure any of these are super clean.
– Rup
Nov 24 '18 at 23:31
2
Returning two different types is generally a bad idea. You could simply setup a "valid" flag in your MyNewEntry class that indicates success or failure.
– Idle_Mind
Nov 24 '18 at 23:32
1
Yea, I was trying to avoid modifying the types as they are third party. I think I'll just make a wrapper class that knows how to handle it.
– mwilson
Nov 24 '18 at 23:32
Use aTuple? A parent class? Really sounds like you should be throwing an exception though. Validation fails aren’t something you can resolve in compile time
– Caius Jard
Nov 24 '18 at 23:57
1
This would be exception driven design, and given the impact that exceptions have on the application, this should be avoided under all circumstances. Avoid throwing exceptions, when you know what can happen. Validation-Result, no matter what kind, are not exceptions.
– Chris
Nov 25 '18 at 0:02
3
3
AFAIK there isn't anything built-in. You could wrap them in an Either structure (like Scala has), or e.g. wrap the validation error in an exception, or return one as an out param and the other one null if set, but I'm not sure any of these are super clean.
– Rup
Nov 24 '18 at 23:31
AFAIK there isn't anything built-in. You could wrap them in an Either structure (like Scala has), or e.g. wrap the validation error in an exception, or return one as an out param and the other one null if set, but I'm not sure any of these are super clean.
– Rup
Nov 24 '18 at 23:31
2
2
Returning two different types is generally a bad idea. You could simply setup a "valid" flag in your MyNewEntry class that indicates success or failure.
– Idle_Mind
Nov 24 '18 at 23:32
Returning two different types is generally a bad idea. You could simply setup a "valid" flag in your MyNewEntry class that indicates success or failure.
– Idle_Mind
Nov 24 '18 at 23:32
1
1
Yea, I was trying to avoid modifying the types as they are third party. I think I'll just make a wrapper class that knows how to handle it.
– mwilson
Nov 24 '18 at 23:32
Yea, I was trying to avoid modifying the types as they are third party. I think I'll just make a wrapper class that knows how to handle it.
– mwilson
Nov 24 '18 at 23:32
Use a
Tuple? A parent class? Really sounds like you should be throwing an exception though. Validation fails aren’t something you can resolve in compile time– Caius Jard
Nov 24 '18 at 23:57
Use a
Tuple? A parent class? Really sounds like you should be throwing an exception though. Validation fails aren’t something you can resolve in compile time– Caius Jard
Nov 24 '18 at 23:57
1
1
This would be exception driven design, and given the impact that exceptions have on the application, this should be avoided under all circumstances. Avoid throwing exceptions, when you know what can happen. Validation-Result, no matter what kind, are not exceptions.
– Chris
Nov 25 '18 at 0:02
This would be exception driven design, and given the impact that exceptions have on the application, this should be avoided under all circumstances. Avoid throwing exceptions, when you know what can happen. Validation-Result, no matter what kind, are not exceptions.
– Chris
Nov 25 '18 at 0:02
|
show 3 more comments
1 Answer
1
active
oldest
votes
To do this, you could use a Result-Type, wich consists of a Property "bool Success" and a Error as well as a Entry property of which always only one is filled with a value, depending on the success of your method.
public class CreateEntryResult
{
public bool Success {get;set;}
public MyNewEntry Entry {get;set;}
public ValdidationError Error {get;set;}
}
To save some memory (you would create an additional object on every result), you may also return a struct. Just replace the "class" keyword in my code with "struct". The contained references will then be passed as values, and you dont have to think about any impact to the garbage collection.
Another way of doing this, which i haven't seen alot in recent years is the "Try" pattern, where you return a result type (normally a bool) and use out-parameters to return your values.
Im not sure how out-parameters work together with async.
bool TryCreateEntry(..., out MyNewEntry entry, out ValidationError error)
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
To do this, you could use a Result-Type, wich consists of a Property "bool Success" and a Error as well as a Entry property of which always only one is filled with a value, depending on the success of your method.
public class CreateEntryResult
{
public bool Success {get;set;}
public MyNewEntry Entry {get;set;}
public ValdidationError Error {get;set;}
}
To save some memory (you would create an additional object on every result), you may also return a struct. Just replace the "class" keyword in my code with "struct". The contained references will then be passed as values, and you dont have to think about any impact to the garbage collection.
Another way of doing this, which i haven't seen alot in recent years is the "Try" pattern, where you return a result type (normally a bool) and use out-parameters to return your values.
Im not sure how out-parameters work together with async.
bool TryCreateEntry(..., out MyNewEntry entry, out ValidationError error)
add a comment |
To do this, you could use a Result-Type, wich consists of a Property "bool Success" and a Error as well as a Entry property of which always only one is filled with a value, depending on the success of your method.
public class CreateEntryResult
{
public bool Success {get;set;}
public MyNewEntry Entry {get;set;}
public ValdidationError Error {get;set;}
}
To save some memory (you would create an additional object on every result), you may also return a struct. Just replace the "class" keyword in my code with "struct". The contained references will then be passed as values, and you dont have to think about any impact to the garbage collection.
Another way of doing this, which i haven't seen alot in recent years is the "Try" pattern, where you return a result type (normally a bool) and use out-parameters to return your values.
Im not sure how out-parameters work together with async.
bool TryCreateEntry(..., out MyNewEntry entry, out ValidationError error)
add a comment |
To do this, you could use a Result-Type, wich consists of a Property "bool Success" and a Error as well as a Entry property of which always only one is filled with a value, depending on the success of your method.
public class CreateEntryResult
{
public bool Success {get;set;}
public MyNewEntry Entry {get;set;}
public ValdidationError Error {get;set;}
}
To save some memory (you would create an additional object on every result), you may also return a struct. Just replace the "class" keyword in my code with "struct". The contained references will then be passed as values, and you dont have to think about any impact to the garbage collection.
Another way of doing this, which i haven't seen alot in recent years is the "Try" pattern, where you return a result type (normally a bool) and use out-parameters to return your values.
Im not sure how out-parameters work together with async.
bool TryCreateEntry(..., out MyNewEntry entry, out ValidationError error)
To do this, you could use a Result-Type, wich consists of a Property "bool Success" and a Error as well as a Entry property of which always only one is filled with a value, depending on the success of your method.
public class CreateEntryResult
{
public bool Success {get;set;}
public MyNewEntry Entry {get;set;}
public ValdidationError Error {get;set;}
}
To save some memory (you would create an additional object on every result), you may also return a struct. Just replace the "class" keyword in my code with "struct". The contained references will then be passed as values, and you dont have to think about any impact to the garbage collection.
Another way of doing this, which i haven't seen alot in recent years is the "Try" pattern, where you return a result type (normally a bool) and use out-parameters to return your values.
Im not sure how out-parameters work together with async.
bool TryCreateEntry(..., out MyNewEntry entry, out ValidationError error)
answered Nov 24 '18 at 23:59
ChrisChris
30018
30018
add a comment |
add a comment |
3
AFAIK there isn't anything built-in. You could wrap them in an Either structure (like Scala has), or e.g. wrap the validation error in an exception, or return one as an out param and the other one null if set, but I'm not sure any of these are super clean.
– Rup
Nov 24 '18 at 23:31
2
Returning two different types is generally a bad idea. You could simply setup a "valid" flag in your MyNewEntry class that indicates success or failure.
– Idle_Mind
Nov 24 '18 at 23:32
1
Yea, I was trying to avoid modifying the types as they are third party. I think I'll just make a wrapper class that knows how to handle it.
– mwilson
Nov 24 '18 at 23:32
Use a
Tuple? A parent class? Really sounds like you should be throwing an exception though. Validation fails aren’t something you can resolve in compile time– Caius Jard
Nov 24 '18 at 23:57
1
This would be exception driven design, and given the impact that exceptions have on the application, this should be avoided under all circumstances. Avoid throwing exceptions, when you know what can happen. Validation-Result, no matter what kind, are not exceptions.
– Chris
Nov 25 '18 at 0:02