Exceptions vs Error codes - c#

Right now we have a set of so called 'services' - classes, that have methods with common signature: their result type have a property T? Error, where T is enum.
And we have a separate enum for each method with a set of values defined for specific method.
This works rather good as long as the final place where we use these services' methods from is controllers' actions — these errors are returned to client, where they are handled by javascript.
But sometime we want to compose some methods of calls of other services' methods, and it is the place where I seem to have a problem.
Let's say we have service's method A(), that has error of type AError. And this A() method calls internally method B() that has an error of type BError.
First of all, we have to map possible BError to AError.
And also it is possible to forget to inspect B's error, and its presence will remain unobserved.
Of cource I know that it is common to use exceptions to indicate that a method has failed.
Right now all controllers have a filter that intercepts unhandled exceptions and returns an answer with just single property Error with value 'InternalServerError'.
But if we start to use exceptions we will loose one feature that I consider important: now a possible set of method's errors is explicitly specified in its signature, and this will be lost in case of we use exceptions.
I know that there is a tag in xml-documentation to list exception types, but it is only documentation, it is not checked by a compiler.
Also I do not understand how to use exceptions on our code:
Let's say we have some method that first checks order's status. Right now it returns 'InvalidOrderStatus' error if order's status is invalid for current action.
If we use exceptions, we can create an exception InvalidOrderStatusException, but how can we know that code that we call internally throws it?
We can also create a mnemonic rule: method A should have error type AError, and inside it should throw some generic exception (let's say, ErrorException<>), parametrized by this AError. And we can intercept this generic exception ErrorException<AError> in all A's calls and observe its error code. But this will not be checked by a compiler: Method A can throw any other exception, or ErrorException<>, but parametrized by some other error code.
So my question is: what is the best way to a) always know what kind of exceptions method can throw and what kind of errors it can return, and b) not be able to forget to observe method's result error?

How about exchanging enum AError with something like this:
class ErrorHolder<T> // T would be AError, BError
{
T ErrorCode {get;}
object[] InnerErrors {get;}
// other payload could go here like inner exceptions etc.
}
Thus you have the enumerated error codes which can be somehow checked plus you can add whatever payload you need.

Create some base exception with desired behaviuor, provide base mechanizm for it's handling, processing and conversion to a result that's being sent to javascript. It doesn't mean that you need to know a list of all possbile exceptions of your method (probaly such list will always be a lie because of possbile non-business exceptions). So derived exceptions can be just a substitutions for error codes, containing specific messages and other data (error code :) ). As you say - "a possible set of method's errors is explicitly specified in its signature" imho it's not an important feature. You should be "object oriented" think of general exception handling (at controller method code level like HandleError(ExecuteService()) or at action filter level). Also, you error codes can be appear not an exceptions but some "execution results" with success or fail status, it's not an exceptional behaviour like "entity not found" but an expected result from service. In this case I use the following code
public class ExecutionResult
{
public ExecutionResult() : this(null)
{
}
public ExecutionResult(ExecutionResult result)
{
if (result != null)
{
Success = result.Success;
Errors = new List<ErrorInfo>(result.Errors);
}
else
{
Errors = new List<ErrorInfo>();
}
}
private bool? _success;
public bool Success
{
get { return _success ?? Errors.Count == 0; }
set { _success = value; }
}
public IList<ErrorInfo> Errors { get; private set; }
}
/*T is for result (any business object)*/
public class ExecutionResult<T> : ExecutionResult
{
public ExecutionResult() : this(null)
{
}
public ExecutionResult(T result) : this(null)
{
Value = result;
}
public ExecutionResult(ExecutionResult result)
: base(result)
{
var r = result as ExecutionResult<T>;
if (r != null)
{
Value = r.Value;
}
}
public T Value { get; set; }
}

So my question is: what is the best way to a) always know what kind of
exceptions method can throw and what kind of errors it can return, and
b) not be able to forget to observe method's result error?
To address "a":
It's hard to do this at compile time. But you can do it via reflection at runtime. See the static enumValues field in the ErrorHandlerFor<T> class.
To address "b", you could do it like this:
In brief: instead of a switch after the call, you prepare error handlers (formerly in the case parts) as lambdas and put all of them in a ErrorHandlerFor<T> class and pass this to the function. This adds the additional benefit of giving feedback to the function whether to continue or abort.
You can also think of this like this:
Assume you want to give some work to a fellow. This work can fail in several ways.
Traditionally you gave the fellow the work and waited till it was finished, maybe with errors. You then handled the errors if necessary.
Now you give the fellow also some "phone numbers" to call when certain errors arise. The answer to the call may even guide the fellow if the work can be continued or needs to be aborted.
enum AError
{
AError1,
AError2,
AError3,
AError4,
AError5,
}
delegate bool SingleErrorHandlerDelegate<T>(T error, object someOtherPayload);
interface IHandle<T>
{
bool Handle(T error, object someOtherPayload); // return true if handled;
}
class ErrorHandlerFor<T> : IHandle<T>
{
private Dictionary<T, SingleErrorHandlerDelegate<T>> handlers;
private static T[] enumValues = Enum.GetValues(typeof(T)).Cast<T>().ToArray();
public ErrorHandlerFor(IEnumerable<KeyValuePair<IEnumerable<T>, SingleErrorHandlerDelegate<T>>> handlers)
: this(handlers.SelectMany(h => h.Key.Select(key => new KeyValuePair<T, SingleErrorHandlerDelegate<T>>(key, h.Value))))
{
}
public ErrorHandlerFor(IEnumerable<KeyValuePair<IEnumerable<T>, SingleErrorHandlerDelegate<T>>> handlers, SingleErrorHandlerDelegate<T> fallbackHandler)
: this(handlers.SelectMany(h => h.Key.Select(key => new KeyValuePair<T, SingleErrorHandlerDelegate<T>>(key, h.Value))), fallbackHandler)
{
}
public ErrorHandlerFor(IEnumerable<KeyValuePair<T, SingleErrorHandlerDelegate<T>>> handlers)
{
this.handlers = new Dictionary<T, SingleErrorHandlerDelegate<T>>();
foreach (var handler in handlers)
{
Debug.Assert(handler.Value != null);
this.handlers.Add(handler.Key, handler.Value);
}
checkHandlers();
}
public ErrorHandlerFor(IEnumerable<KeyValuePair<T, SingleErrorHandlerDelegate<T>>> handlers, SingleErrorHandlerDelegate<T> fallbackHandler)
{
this.handlers = new Dictionary<T, SingleErrorHandlerDelegate<T>>();
foreach (var handler in handlers)
{
Debug.Assert(handler.Value != null);
this.handlers.Add(handler.Key, handler.Value);
}
foreach (var enumValue in enumValues)
{
if (this.handlers.ContainsKey(enumValue) == false)
{
this.handlers.Add(enumValue, fallbackHandler);
}
}
checkHandlers();
}
private void checkHandlers()
{
foreach (var enumValue in enumValues)
{
Debug.Assert(handlers.ContainsKey(enumValue));
}
}
public bool Handle(T error, object someOtherPayload)
{
return handlers[error](error: error, someOtherPayload: someOtherPayload);
}
}
class Test
{
public static void test()
{
var handler = new ErrorHandlerFor<AError>(
new[]{
new KeyValuePair<IEnumerable<AError>, SingleErrorHandlerDelegate<AError>>(
new []{AError.AError1, AError.AError2, AError.AError4,},
(AError error, object payload) => { Console.WriteLine(#"handled error 1, 2 or 4!"); return true;}
),
new KeyValuePair<IEnumerable<AError>, SingleErrorHandlerDelegate<AError>>(
new []{AError.AError3, AError.AError5,},
(AError error, object payload) => { Console.WriteLine(#"could not handle error 3 or 5!"); return false;}
),
}
);
var result = Services.foo(handler);
var incompleteHandlerButWithFallbackThatWillPassTheTest = new ErrorHandlerFor<AError>(
new[]{
new KeyValuePair<IEnumerable<AError>, SingleErrorHandlerDelegate<AError>>(
new []{AError.AError1, AError.AError2, AError.AError4,},
(AError error, object payload) => { Console.WriteLine(#"handled error 1, 2 or 4!"); return true;}
),
new KeyValuePair<IEnumerable<AError>, SingleErrorHandlerDelegate<AError>>(
new []{AError.AError5},
(AError error, object payload) => { Console.WriteLine(#"could not handle error 3 or 5!"); return false;}
),
}
// AError.AError3 is not handled! => will go in fallback
, (AError error, object payload) => { Console.WriteLine(#"could not handle error in fallback!"); return false; }
);
var result2 = Services.foo(incompleteHandlerButWithFallbackThatWillPassTheTest);
var incompleteHandlerThatWillBeDetectedUponInstantiation = new ErrorHandlerFor<AError>(
new[]{
new KeyValuePair<IEnumerable<AError>, SingleErrorHandlerDelegate<AError>>(
new []{AError.AError1, AError.AError2, AError.AError4,},
(AError error, object payload) => { Console.WriteLine(#"handled error 1, 2 or 4!"); return true;}
),
new KeyValuePair<IEnumerable<AError>, SingleErrorHandlerDelegate<AError>>(
new []{AError.AError3},
(AError error, object payload) => { Console.WriteLine(#"could not handle error 3 or 5!"); return false;}
),
} // AError.AError5 is not handled! => will trigger the assertion!
);
}
}
class Services
{
public static Result foo(IHandle<AError> errorHandler)
{
Debug.Assert(errorHandler != null);
// raise error...
var myError = AError.AError1;
var handled = errorHandler.Handle(error: myError, someOtherPayload: "hello");
if (!handled)
return new Result();
// maybe proceed
var myOtherError = AError.AError3;
errorHandler.Handle(error: myOtherError, someOtherPayload: 42); //we'll return anyway in this case...
return new Result();
}
public class Result
{
}
}

Related

Passing an interface method as a parameter

Note: This could very well be very C# specific language question, unrelated to WCF or web services at all.
There is a 3-party ASMX web service, which shall be used for data retrieval. I have created a generalized method called ExecuteCommand() which is used for every request against the web service. The purpose of this method is to handle cookie session/exceptions and other common logic. For each request a new channel shall be used, in order to simplify the disposal of unused resources.
The problem is that to use the ExecuteCommand() method - I have to initialize a channel each time, in order to be able to pass the method to be executed as an argument. Sorry if it sounds too complicated. Here is a usage example:
string color = "blue";
var channel = _strategyFactory.CreateChannel<CarServiceSoapChannel>();
var cars = WcfHelper.ExecuteCommand(channel, () => channel.GetCars(color));
// channel is null here. Channel was closed/aborted, depending on Exception type.
After ExecuteCommand() is called - channel is already disposed of. The reason why channel object is needed at all, is to be able to provide a method to be executed as a parameter! i.e.() => channel.GetCars(). To further support these words, here is the WcfHelper class internals:
public static class WcfHelper
{
public static Cookie Cookie { get; set; }
public static T ExecuteCommand<T>(IClientChannel channel, Expression<Func<T>> method)
{
T result = default(T);
try
{
// init operation context
using (new OperationContextScope(channel))
{
// set the session cookie to header
if (Cookie != null) {
HttpRequestMessageProperty request = new HttpRequestMessageProperty();
request.Headers["Cookie"] = cookie.ToString();
OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = request;
}
// execute method
var compiledMethod = method.Compile();
result = compiledMethod.Invoke();
}
}
// do different logic for FaultException, CommunicationException, TimeoutException
catch (Exception)
{
throw;
}
finally
{
CloseOrAbortServiceChannel(channel);
channel = null;
}
return result;
}
private static void CloseOrAbortServiceChannel(ICommunicationObject communicationObject)
{
bool isClosed = false;
if (communicationObject == null || communicationObject.State == CommunicationState.Closed)
return;
try
{
if (communicationObject.State != CommunicationState.Faulted)
{
communicationObject.Close();
isClosed = true;
}
}
catch (Exception)
{
throw;
}
finally
{
if (!isClosed)
AbortServiceChannel(communicationObject);
}
}
private static void AbortServiceChannel(ICommunicationObject communicationObject)
{
try
{
communicationObject.Abort();
}
catch (Exception)
{
throw;
}
}
}
So the short question - it it possible to initialize a channel variable inside the ExecuteCommand method itself, while having a possibility to define, which method shall be executed inside ExecuteCommand for a given channel?
I am trying to accomplish something like this:
string color = "blue";
var cars = WcfHelper.ExecuteCommand<Car[], CarServiceSoapChannel>(channel => channel.GetCars(color));
or even
string color = "blue";
var cars = WcfHelper.ExecuteCommand<CarServiceSoapChannel>(channel => channel.GetCars(color));
Any other code improvement suggestions are welcomed but not mandatory, of course.
P.S. ASMX is added as a Service reference in Visual Studio. Therefore, there were some entities that automatically generated for the "CarService", such as - CarServiceSoapChannel interface, CarServiceSoapClient class and of course CarService interface containing methods of a web service. In the example above a ChannelFactory is used to create a channel for the CarServiceSoapChannel interface, hence, here is where the question name is coming from: Passing an interface method as a parameter. This could be a bit misleading, but I hope it's clear what I trying to accomplish from the description itself.
Update 25.05.2018
I followed the advice of #nvoigt and was able to achieve the result I wanted:
public static TResult ExecuteCommand<TInterface, TResult>(Func<TInterface, TResult> method)
where TInterface : IClientChannel
{
TResult result = default(TResult);
IClientChannel channel = null;
try
{
channel = StrategyFactory.CreateChannel<TInterface>();
// init operation context
using (new OperationContextScope(channel))
{
// set the session cookie to header
if (Cookie != null)
Cookie.SetCookieForSession();
// execute method
result = method((TInterface)channel);
}
}
catch (Exception)
{
throw;
}
finally
{
CloseOrAbortServiceChannel(channel);
channel = null;
}
return result;
}
This already achieves the initial goal. There is, however, one issue with this approach. In order to call the method - you have to explicitly specify the method's return parameter.
So to say, if you want to call the method - writing this is not enough:
var result = WcfHelper.ExecuteCommand<CarServiceSoapChannel>(channel => channel.IsBlue())
You will have to specifically specify, that the return type shall be boolean
var result = WcfHelper.ExecuteCommand<CarServiceSoapChannel, bool>(channel => channel.IsBlue())
I personally don't mind writing an extra bit of code, as it is still a big advantage over my initial method implementation, however, I am wondering in the new version could be improved?
For example, When I had just 1 generic TResult type in the method - the return type <TResult> could be omitted. This is no longer the case with 2 generics. In any case, thank you #nvoigt!
Your method signature should be:
public static TResult ExecuteCommand<TInterface>(Func<TInterface, TResult> method)
Then in your WcfHelper (which should probably not be static anymore because it needs a member _strategyFactory) you create a channel as before:
{
var channel = _strategyFactory.CreateChannel<CarServiceSoapChannel>();
return method(channel);
}
Obviously, you need to add all the fancy try/finally stuff again.
As you should have instances anyway now with the factory in the class as a member, you could put the service contract generic into your class to make it easier for users:
public class ConnectionToService<TInterface> : where TInterface : class
{
public TResult ExecuteCommand<TResult>(Func<TInterface, TResult> method)
{
var channel = _strategyFactory.CreateChannel<CarServiceSoapChannel>();
return method(channel);
}
}
Usage:
var service = new ConnectionToService<ICarService>();
var color = service.ExecuteCommand(s => s.GetColor());

Same type exception from different places

Let's say you have two different libraries that you write for different format of files. One parses type A of file and one parses type B. Now I see that in most cases most folks say that the exceptions already defined (let's say we use C# and .NET) are enough to handle most situations. In this case I think that is OK that in both cases we if we encounter some problems when parsing we throw a InvalidDataException that tells us that the format is not correct.What happens when we must catch both exceptions in a higher level function that must do something with them?
void SomeHigherFunction()
{
try
{
int x = GetSomeDataFromFileA(); // throws InvalidDataException
int y = GetSomeDataFromFileB(); // throws InvalidDataException
}
catch(InvalidDataException) // what failed ?
{
ShowMessageWithWhatFileFailed() // what display ?
}
}
How do we know where the code failed? Should in this case be two different Exception types defined, one TypeAException and one TypeBException or is something easy here that I miss? I don't want to wrap each function and return a bool with the result. In this case I would wrap function A in a function and let it return true if successful and execute B further. But that is clearly a bad design and wrong use of exceptions. Should I just create new types in this cases ? Or how?
You can use Exception.Data Collection to pass the owner of the Exception and do something with it further.
I refactored your example a little, but i think this fits your requirements:
class Program
{
[Serializable]
public abstract class Parser
{
public int GetData()
{
bool error = true;
if (error)
{
InvalidDataException exception = new InvalidDataException();
exception.Data.Add("owner", this);
throw exception;
}
return 0;
}
public abstract void handleError();
}
[Serializable]
private class ParserA : Parser
{
public override void handleError()
{
Console.WriteLine("Handled in A");
}
}
[Serializable]
private class ParserB : Parser
{
public override void handleError()
{
Console.WriteLine("Handled in B");
}
}
static void Main(String[] args)
{
try
{
int x = new ParserA().GetData();
int y = new ParserB().GetData();
}
catch (InvalidDataException ex)
{
Parser parser = ex.Data["owner"] as Parser;
if(parser != null)
parser.handleError();
// or even this if you prefer:
if (parser is ParserA)
Console.WriteLine("A");
}
}
}
In a real case scenario GetData method would be virtual, but you got the idea

Getting parameter name and value from delegate

I have implemented a generic method for calling function in my web service methods and catching exceptions. The idea is to centralize the exception handling and log why the exception occured:
public class WebServiceHandler
{
public T Execute<T>(Func<T> body)
{
//wrap everything in common try/catch
try
{
return body();
}
catch (SoapException)
{
//rethrow any pre-generated SOAP faults
throw;
}
catch (Exception ex)
{
Logger.AddTextToLog(Logger.LogLevel.Error, "An error occured");
var innerExceptionMessage = ex.InnerException != null ? ex.InnerException.Message : "";
throw GenerateSoapException(
ex.Message,
innerExceptionMessage,
SoapException.ServerFaultCode);
}
}
}
I'm using the method like this in my web service methods:
[WebMethod]
GetXXX(string param1, string param2)
{
var request = new GetXXXRequest(param1, param2);
return _webServiceHandler.Execute(() => _controller.GetXXX(request));
}
[WebMethod]
GetYYY(string param1)
{
var request = new GetYYYRequest(param1);
return _webServiceHandler.Execute(() => _controller.GetYYY(request));
}
In case of exceptions I would like to log the parameter names and values used as input to the controller.GetXXX(request) and controller.GetYYY(request) methods in the Execute method.
How can I achieve this?
Or is there a better way to achieve the same goal?
I did not tried with expressions but I have a solution for delegates;
public static List<object> GetMethodParameterValues(Delegate method)
{
var target = method.Target;
if (target == null) return null;
var fields = target.GetType().GetFields();
var valueList = fields.Select(field => field.GetValue(target)).ToList();
return valueList;
}
First of all you can't query the runtime for the that information magically, implicitly.
It is true that you can implicitly learn the complete identity of the currently executing method, its caller, its caller's caller and all of the stacktrace (except for the particular generic arguments in case of generic methods) by instantiating the StackTrace class or by calling the MethodBase.GetCurrentMethod() method.
It is also true that the resulting MethodBase instances hold information about the methods' parameters and so, you might be able to learn the names of the parameters, but that's where it all ends. If a mechanism allowing you to implicitly probe for parameter or local variable values would've been invented then everything would be a lot slower.
What you can do, is help yourself, a bit, by means of the Expression<Lambda> class and its entourage. It's gonna be a bit slow, but you get to choose whether you want reviewable and easy to manage code, or misteriously hard to manage and very very fast code.
Expression<Lambda> is how LINQ manages to not do a full table scan of database tables but rather understand what you did with your query and translate that (at runtime) into SQL or whatever other language you might imagine (depending on the actual LINQ provider).
First of all, I would suggest splitting concerns into 2 categories:
Retrieving names and values (as implicitly as possible)
Using names and values (wherever you want to)
To make that happen you need to think about an entity which can hold the results of point 1. In my suggestion to you that would be a kind of Dictionary<string, object> but you can do whatever suits you best.
My suggestion can be used like so:
public void SomeMethod(string x, int y) {
IDictionary<string, object> paramValues = Helper.TapInto(
() => x,
() => y
);
// paramValues["x"] an paramValues["y"] will hold the values of x and y
}
So, on to the coding bit. You could write a Helper class like so:
public static class Helper {
}
In that Helper class you could invent a static method ( I called mine TapInto maybe that's not the best name for it ) which receives a primitive array of Expression<Func<object>> instances. It does that with a params modifier so that you can easily pass implicit lambdas to it. As a return it gives you a hashtable from string to object representing the "decompiled" variable names and their associated values.
In my case, I also created a private overload of that same method which is actually an "extension" method, to make the code clearer.
public static class Helper {
// ... an overload of the TapInto method is about to appear right here
public static IDictionary<string, object> TapInto(params Expression<Func<object>>[] parameterTouchers) {
var result = new Dictionary<string, object>();
foreach (var toucher in parameterTouchers) {
string name;
object value;
toucher.TapInto(out name, out value);
result[name] = value;
}
return result;
}
So all the public method does is iterate through the list and accumulate the yielded results into the dictionary.
Next let's look at the real magic, which happens in the toucher.TapInto(out name, out value) call:
public static class Helper {
private static void TapInto(this Expression<Func<object>> #this, out string name, out object value) {
Expression expression = #this.Body;
if (expression is UnaryExpression)
expression = (expression as UnaryExpression).Operand;
name = (expression as MemberExpression).Member.Name;
Func<object> compiledLambda = #this.Compile();
value = compiledLambda();
}
// ... public helper method right here
}
What we're doing here is "we're looking inside" the lambda with a magnifying glass.
Because we're gonna use stuff other than object variables it's imminent to observe an implicit conversion like
.. int someParameter ..
object obj = someParameter;
which is only implicit in the actual C# code, but is actually compiled as an explicit conversion:
object obj = (object)someParameter;
But you might have a plain object parameter, like object anotherParam, in which case there would be no conversion at all.
That is why, upon observing the expression's intricate details, I presume I might find a conversion ( represented by the UnaryExpression class ) or not.
Actually it's like saying: In this particular case, my contract to the calling code is that it may send me only stuff which falls into these 2 categories:
Immediate object variable reference: () => someObjectVariable
Variable reference with a conversion: () => (object)x
The contract also accidentally states that the "conversion" bit can be replaced by a UnaryExpression, for instance: () => !someBool.
It also states that you cannot do something like:
() => 123
or () => a + b + c + 100
or anything else in those directions
So, to wrap it up:
You could write your nice little helper
You could use it wherever you want to use it to produce maps between param names and their values although it's not 100% implicit, but at least it won't compile if you rename a parameter without complete refactoring or it will let you rename the parameter references if you choose to rename the parameters using refactoring
(it also works on fields, local variables, etc)
Pass your dictionaries in between parts of your code that are interested in them and use them accordingly !
You can use another parameter to the Execute method to get callback from function.
An Action or your result type. In this case string for example:
public T Execute<T>(Func<T> body, Action<string> callback)
{
//wrap everything in common try/catch
try
{
//do stuff
callback("results are...");
}
You can also use a delegate:
public void CallbackDelegate( string str );
public T Execute<T>(Func<T> body, CallbackDelegate callback)
{
//wrap everything in common try/catch
try
{
//do stuff
callback("results are...");
}
Maybe something like this:
sealed class Param
{
public string Name
{
get;
private set;
}
public object Value
{
get;
private set;
}
public Param(string name, object value)
{
Name = name;
Value = value;
}
}
public T Execute<T>(Func<T> body, params Param[] parameters)
{
//wrap everything in common try/catch
try
{
return body();
}
catch (SoapException)
{
//rethrow any pre-generated SOAP faults
throw;
}
catch (Exception ex)
{
Logger.AddTextToLog(Logger.LogLevel.Error, "An error occured");
foreach (var parameter in parameters)
{
Logger.AddTextToLog(
Logger.LogLevel.Error,
string.Format(
"{0} : {1}",
parameter.Name,
parameter.Value ?? "null"));
}
var innerExceptionMessage = ex.InnerException != null ? ex.InnerException.Message : "";
throw GenerateSoapException(
ex.Message,
innerExceptionMessage,
SoapException.ServerFaultCode);
}
}
And then you call:
[WebMethod]
GetXXX(string param1, string param2)
{
var request = new GetXXXRequest(param1, param2);
return _webServiceHandler.Execute(() => _controller.GetXXX(request)
new Parameter("param1", param1),
new Parameter("param2", param2));
}
What I ended up doing was to add the request class as parameter to the Execute method like this:
public T Execute<T, TU>(Func<T> body, TU parameterClass) where TU : class
{
//wrap everything in common try/catch
try
{
return body();
}
catch (SoapException)
{
//rethrow any pre-generated SOAP faults
throw;
}
catch (Exception ex)
{
var serializedObject = ParameterUtil.GetPropertyNamesAndValues(parameterClass);
Logger.AddTextToLog(Logger.LogLevel.Error, string.Format("An error occured when calling braArkiv Web Services. Web service method arguments: {0}", serializedObject), ex);
var innerExceptionMessage = ex.InnerException != null ? ex.InnerException.Message : "";
throw GenerateSoapException(
ex.Message,
innerExceptionMessage,
SoapException.ServerFaultCode);
}
}
public static class ParameterUtil
{
public static string GetPropertyNamesAndValues<T>(T o) where T : class
{
using (var stringWriter = new StringWriter())
{
var xmlSerializer = new XmlSerializer(o.GetType());
xmlSerializer.Serialize(stringWriter, o);
stringWriter.Close();
return stringWriter.ToString();
}
}
}
Usage:
[WebMethod]
GetXXX(string param1, string param2)
{
var request = new GetXXXRequest(param1, param2);
return _webServiceHandler.Execute(() => _controller.GetXXX(request), request);
}
When an exception occurs I just serialize the parameterClass parameter containing the web service method parameters and add the string to my log.
Thank you all for the constructive input to my question!

Which result pattern is best for a public API and why?

There are a few different common patterns for returning the result of a function call in public APIs. It is not obvious which is the best approach. Is there a general consensus on a best practice, or, at least convincing reasons why one pattern is better the others?
Update By public API, I mean the public members that are exposed to dependent assemblies. I am not referring exclusively to an API that is exposed publicly as a web service. We can make the assumption that clients are using .NET.
I wrote a sample class below to illustrate the different patterns for returning values, and I have annotated them expressing my concerns for each one.
This is a bit of a long question, but I'm sure I'm not the only person to have considered this and hopefully this question will be interesting to others.
public class PublicApi<T> // I am using the class constraint on T, because
where T: class // I already understand that using out parameters
{ // on ValueTypes is discouraged (http://msdn.microsoft.com/en-us/library/ms182131.aspx)
private readonly Func<object, bool> _validate;
private readonly Func<object, T> _getMethod;
public PublicApi(Func<object,bool> validate, Func<object,T> getMethod)
{
if(validate== null)
{
throw new ArgumentNullException("validate");
}
if(getMethod== null)
{
throw new ArgumentNullException("getMethod");
}
_validate = validate;
_getMethod = getMethod;
}
// This is the most intuitive signature, but it is unclear
// if the function worked as intended, so the caller has to
// validate that the function worked, which can complicates
// the client's code, and possibly cause code repetition if
// the validation occurs from within the API's method call.
// It also may be unclear to the client whether or not this
// method will cause exceptions.
public T Get(object argument)
{
if(_validate(argument))
{
return _getMethod(argument);
}
throw new InvalidOperationException("Invalid argument.");
}
// This fixes some of the problems in the previous method, but
// introduces an out parameter, which can be controversial.
// It also seems to imply that the method will not every throw
// an exception, and I'm not certain in what conditions that
// implication is a good idea.
public bool TryGet(object argument, out T entity)
{
if(_validate(argument))
{
entity = _getMethod(argument);
return true;
}
entity = null;
return false;
}
// This is like the last one, but introduces a second out parameter to make
// any potential exceptions explicit.
public bool TryGet(object argument, out T entity, out Exception exception)
{
try
{
if (_validate(argument))
{
entity = _getMethod(argument);
exception = null;
return true;
}
entity = null;
exception = null; // It doesn't seem appropriate to throw an exception here
return false;
}
catch(Exception ex)
{
entity = null;
exception = ex;
return false;
}
}
// The idea here is the same as the "bool TryGet(object argument, out T entity)"
// method, but because of the Tuple class does not rely on an out parameter.
public Tuple<T,bool> GetTuple(object argument)
{
//equivalent to:
T entity;
bool success = this.TryGet(argument, out entity);
return Tuple.Create(entity, success);
}
// The same as the last but with an explicit exception
public Tuple<T,bool,Exception> GetTupleWithException(object argument)
{
//equivalent to:
T entity;
Exception exception;
bool success = this.TryGet(argument, out entity, out exception);
return Tuple.Create(entity, success, exception);
}
// A pattern I end up using is to have a generic result class
// My concern is that this may be "over-engineering" a simple
// method call. I put the interface and sample implementation below
public IResult<T> GetResult(object argument)
{
//equivalent to:
var tuple = this.GetTupleWithException(argument);
return new ApiResult<T>(tuple.Item1, tuple.Item2, tuple.Item3);
}
}
// the result interface
public interface IResult<T>
{
bool Success { get; }
T ReturnValue { get; }
Exception Exception { get; }
}
// a sample result implementation
public class ApiResult<T> : IResult<T>
{
private readonly bool _success;
private readonly T _returnValue;
private readonly Exception _exception;
public ApiResult(T returnValue, bool success, Exception exception)
{
_returnValue = returnValue;
_success = success;
_exception = exception;
}
public bool Success
{
get { return _success; }
}
public T ReturnValue
{
get { return _returnValue; }
}
public Exception Exception
{
get { return _exception; }
}
}
Get - use this if validation failing is unexpected or if it's feasible for callers to validate the argument themselves before calling the method.
TryGet - use this if validation failing is expected. The TryXXX pattern can be assumed to be familiar due it's common use in the .NET Framework (e.g., Int32.TryParse or Dictonary<TKey, TValue>.TryGetValue).
TryGet with out Exception - an exception likely indicates a bug in the code passed as delegates to the class, because if the argument was invalid then _validate would return false instead of throwing an exception and _getMethod would not be called.
GetTuple, GetTupleWithException - never seen these before. I wouldn't recommend them, because a Tuple isn't self-explaining and thus not a good choice for a public interface.
GetResult - use this if _validate needs to return more information than a simple bool. I wouldn't use it to wrap exceptions (see: TryGet with out Exception).
If by "public API" you mean an API by will be consumed by applications outside of your control and those client apps will written in a variety of languages/platforms I would suggest returning very basic types (e.g. strings, integers, decimals) and use something like JSON for more complex types.
I don't think you can expose a generic class in a public API since you don't know if the client will support generics.
Pattern-wise I would lean towards a REST-like approach rather than SOAP. Martin Fowler has a good article high level article on what this means: http://martinfowler.com/articles/richardsonMaturityModel.html
Things to consider, before answer:
1- There is a special situation about DOTNet programming languages & Java, due that you can easily retrieve objects, instead of only primitive types. Example: so a "plain C" A.P.I. may differ to a C# A.P.I.
2- If there is an error in you A.P.I., while retriving a data, how to handle, without interrumpting you application.
Answer:
A pattern, I have seen in several libraries, its a function, that its main result its an integer, in which 0 means "success", and another integer value means an specific error code.
The function may have several arguments, mostly read-only or input parameters, and a single reference or out parameter that maybe a primitive type a reference to an object, that maybe changed, or a pointer to an object or data structure.
In case of exceptions, some developers, may catch them and generate an specific error code.
public static class MyClass
{
// not recomended:
int static GetParams(ref thisObject, object Param1, object Params, object Param99)
{
const int ERROR_NONE = 0;
try
{
...
}
catch (System.DivideByZeroException dbz)
{
ERROR_NONE = ...;
return ERROR_NONE;
}
catch (AnotherException dbz)
{
ERROR_NONE = ...;
return ERROR_NONE;
}
return ERROR_NONE;
} // method
// recomended:
int static Get(ref thisObject, object ParamsGroup)
{
const int ERROR_NONE = 0;
try
{
...
}
catch (System.DivideByZeroException dbz)
{
ERROR_NONE = ...;
return ERROR_NONE;
}
catch (AnotherException dbz)
{
ErrorCode = ...;
return ERROR_NONE;
}
return ERROR_NONE;
} // method
} // class
Its similar to your tuple result. Cheers.
UPDATE 1: Mention about exception handling.
UPDATE 2: explicit declare constants.

How to detect if a property exists on an ExpandoObject?

In javascript you can detect if a property is defined by using the undefined keyword:
if( typeof data.myProperty == "undefined" ) ...
How would you do this in C# using the dynamic keyword with an ExpandoObject and without throwing an exception?
According to MSDN the declaration shows it is implementing IDictionary:
public sealed class ExpandoObject : IDynamicMetaObjectProvider,
IDictionary<string, Object>, ICollection<KeyValuePair<string, Object>>,
IEnumerable<KeyValuePair<string, Object>>, IEnumerable, INotifyPropertyChanged
You can use this to see if a member is defined:
var expandoObject = ...;
if(((IDictionary<String, object>)expandoObject).ContainsKey("SomeMember")) {
// expandoObject.SomeMember exists.
}
An important distinction needs to be made here.
Most of the answers here are specific to the ExpandoObject which is mentioned in the question. But a common usage (and reason to land on this question when searching) is when using the ASP.Net MVC ViewBag. That's a custom implementation/subclass of DynamicObject, which won't throw an Exception when you check any arbitrary property name for null. Suppose you might declare a property like:
#{
ViewBag.EnableThinger = true;
}
Then suppose you wanted to check its value, and whether it's even set - whether it exists. The following is valid, will compile, won't throw any exceptions, and gives you the right answer:
if (ViewBag.EnableThinger != null && ViewBag.EnableThinger)
{
// Do some stuff when EnableThinger is true
}
Now get rid of the declaration of EnableThinger. Same code compiles and runs properly. No need for reflection.
Unlike ViewBag, ExpandoObject will throw if you check for null on a property that doesn't exist. In order to get MVC ViewBag's gentler functionality out of your dynamic objects, you'll need to use an implementation of dynamic that doesn't throw.
You could simply use the exact implementation in MVC ViewBag:
. . .
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
result = ViewData[binder.Name];
// since ViewDataDictionary always returns a result even if the key does not exist, always return true
return true;
}
. . .
https://github.com/ASP-NET-MVC/aspnetwebstack/blob/master/src/System.Web.Mvc/DynamicViewDataDictionary.cs
You can see it being tied into MVC Views here, in MVC ViewPage:
http://aspnetwebstack.codeplex.com/SourceControl/latest#src/System.Web.Mvc/ViewPage.cs
The key to DynamicViewDataDictionary's graceful behavior is the Dictionary implementation on ViewDataDictionary, here:
public object this[string key]
{
get
{
object value;
_innerDictionary.TryGetValue(key, out value);
return value;
}
set { _innerDictionary[key] = value; }
}
https://github.com/ASP-NET-MVC/aspnetwebstack/blob/master/src/System.Web.Mvc/ViewDataDictionary.cs
In other words, it always returns a value for all keys, regardless of what's in it - it simply returns null when nothing's there. But, ViewDataDictionary has the burden of being tied to MVC's Model, so it's better to strip out just the graceful dictionary parts for use outside MVC Views.
It's too long to really post all the guts here - most of it just implementing IDictionary - but here's a dynamic object (class DDict) that doesn't throw for null checks on properties that haven't been declared, on Github:
https://github.com/b9chris/GracefulDynamicDictionary
If you just want to add it to your project via NuGet, its name is GracefulDynamicDictionary.
I wanted to create an extension method so I could do something like:
dynamic myDynamicObject;
myDynamicObject.propertyName = "value";
if (myDynamicObject.HasProperty("propertyName"))
{
//...
}
... but you can't create extensions on ExpandoObject according to the C# 5 documentation (more info here).
So I ended up creating a class helper:
public static class ExpandoObjectHelper
{
public static bool HasProperty(ExpandoObject obj, string propertyName)
{
return obj != null && ((IDictionary<String, object>)obj).ContainsKey(propertyName);
}
}
To use it:
// If the 'MyProperty' property exists...
if (ExpandoObjectHelper.HasProperty(obj, "MyProperty"))
{
...
}
UPDATED: You can use delegates and try to get a value from the dynamic object property if it exists. If there is no property, simply catch the exception and return false.
Take a look, it works fine for me:
class Program
{
static void Main(string[] args)
{
dynamic userDynamic = new JsonUser();
Console.WriteLine(IsPropertyExist(() => userDynamic.first_name));
Console.WriteLine(IsPropertyExist(() => userDynamic.address));
Console.WriteLine(IsPropertyExist(() => userDynamic.last_name));
}
class JsonUser
{
public string first_name { get; set; }
public string address
{
get
{
throw new InvalidOperationException("Cannot read property value");
}
}
}
static bool IsPropertyExist(GetValueDelegate getValueMethod)
{
try
{
//we're not interesting in the return value. What we need to know is whether an exception occurred or not
getValueMethod();
return true;
}
catch (RuntimeBinderException)
{
// RuntimeBinderException occurred during accessing the property
// and it means there is no such property
return false;
}
catch
{
//property exists, but an exception occurred during getting of a value
return true;
}
}
delegate string GetValueDelegate();
}
The output of the code is the following:
True
True
False
I answered a very similar question recently: How do I reflect over the members of dynamic object?
Shortly, ExpandoObject is not the only dynamic object you might get. Reflection would work for static types (types that do not implement IDynamicMetaObjectProvider). For types that do implement this interface, reflection is basically useless. For ExpandoObject, you can simply check whether the property is defined as a key in the underlying dictionary. For other implementations, it might be challenging and sometimes the only way is to work with exceptions. For details, follow the link above.
Why you do not want to use Reflection to get set of type properyes? Like this
dynamic v = new Foo();
Type t = v.GetType();
System.Reflection.PropertyInfo[] pInfo = t.GetProperties();
if (Array.Find<System.Reflection.PropertyInfo>(pInfo, p => { return p.Name == "PropName"; }). GetValue(v, null) != null))
{
//PropName initialized
}
This extension method checks for the existence of a property and then returns the value or null. This is useful if you do not want your applications to throw unnecessary exceptions, at least ones you can help.
public static object Value(this ExpandoObject expando, string name)
{
var expandoDic = (IDictionary<string, object>)expando;
return expandoDic.ContainsKey(name) ? expandoDic[name] : null;
}
If can be used as such :
// lookup is type 'ExpandoObject'
object value = lookup.Value("MyProperty");
or if your local variable is 'dynamic' you will have to cast it to ExpandoObject first.
// lookup is type 'dynamic'
object value = ((ExpandoObject)lookup).Value("PropertyBeingTested");
Depending on your use case, if null can be considered as being the same as undefined, you can turn your ExpandoObject into a DynamicJsonObject.
dynamic x = new System.Web.Helpers.DynamicJsonObject(new ExpandoObject());
x.a = 1;
x.b = 2.50;
Console.WriteLine("a is " + (x.a ?? "undefined"));
Console.WriteLine("b is " + (x.b ?? "undefined"));
Console.WriteLine("c is " + (x.c ?? "undefined"));
Output:
a is 1
b is 2.5
c is undefined
(authorDynamic as ExpandoObject).Any(pair => pair.Key == "YourProp");
Hey guys stop using Reflection for everything it costs a lots of CPU cycles.
Here is the solution:
public class DynamicDictionary : DynamicObject
{
Dictionary<string, object> dictionary = new Dictionary<string, object>();
public int Count
{
get
{
return dictionary.Count;
}
}
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
string name = binder.Name;
if (!dictionary.TryGetValue(binder.Name, out result))
result = "undefined";
return true;
}
public override bool TrySetMember(SetMemberBinder binder, object value)
{
dictionary[binder.Name] = value;
return true;
}
}
Try this one
public bool PropertyExist(object obj, string propertyName)
{
return obj.GetType().GetProperty(propertyName) != null;
}

Categories