I have certain code pattern (which log performance and other variable for each function) which need to be present in every function, and I do not want to repeat the code over and over again. Here is what the code looks like:
public OutClass FUNC-X
{
if (IsDebugEnabled)
{
Logger("Start DataLibrary: FUNC-X");
}
try
{
CheckInitSucceeded();
GetAuthenticationTokens();
var dm = new Manager();
/**
* THIS SINGLE LINE IS THE VARIABLE PART
**/
var output = dm.FUNC-X(...);
if (IsDebugEnabled)
{
var data = Serialize(output);
Logger(output);
}
return output;
}
catch (WebFaultException)
{
throw;
}
catch (OtherException ex)
{
if (Logger.IsErrorEnabled)
{
Logger.LogError("Exception in FUNC-X", ex);
}
throw new OtherException("Some Message");
}
catch (Exception ex)
{
if (IsErrorEnabled)
{
Logger("Exception in FUNC-X", ex);
}
throw new Exception("Generic Exception");
}
finally
{
if (IsDebugEnabled)
{
Logger("End FUNC-X");
}
}
}
Essentially, I just need to replace FUNC-X with FUNC-Y or FUNC-Z everywhere this name occurs, is there some kind of design pattern which I can follow?
I'm sorry if the question is vague, I shall be happy to provide any details you ask.
Yeah, there are many ways to provide nice log code.
Use aspect-oriented programming. There is PostSharp and Spring.NET. You can use log4net library. All of them after config supports writing of method name.
You can use T4 and generate code for all funcs before compile.
You can write one global logging method that accepts Func<object> method and string methodName. Suppose you named your logging method LogAndExecute. Then to call you must write smth like:
LogAndExecute("func-x", () => dm.Func-X(/*your args*/))
If you got problems with different different return types of your funcs, use generics
You can use simple delegate to accept the variable part as parameter (if no. of parameters to function call in single line are same)
public void Function_X(Func<object,..> func)
{
if (IsDebugEnabled)
{
Logger("Start DataLibrary: FUNC-X");
}
try
{
CheckInitSucceeded();
GetAuthenticationTokens();
var dm = new Manager();
/**
* THIS SINGLE LINE IS THE VARIABLE PART
**/
// var output = dm.FUNC-X(...);
var output = func(...);
if (IsDebugEnabled)
{
var data = Serialize(output);
Logger(output);
}
return output;
}
catch (WebFaultException)
{
throw;
}
catch (OtherException ex)
{
if (Logger.IsErrorEnabled)
{
Logger.LogError("Exception in FUNC-X", ex);
}
throw new OtherException("Some Message");
}
catch (Exception ex)
{
if (IsErrorEnabled)
{
Logger("Exception in FUNC-X", ex);
}
throw new Exception("Generic Exception");
}
finally
{
if (IsDebugEnabled)
{
Logger("End FUNC-X");
}
}
}
You can create a common function that accepts a Func delegate:
static public TOutClass CommonFunc<TOutClass>(Func<Manager, TOutClass> func)
{
if (IsDebugEnabled)
{
Logger("Start DataLibrary: FUNC-X");
}
try
{
CheckInitSucceeded();
GetAuthenticationTokens();
var dm = new Manager();
TOutClass output = func(dm);
if (IsDebugEnabled)
{
var data = Serialize(output);
Logger(output);
}
return output;
}
catch
[...]
}
Your would write your functions as:
public OutClass FUNC-X(...)
{
return CommonFunc(dm=>dm.FUNC-X(...));
}
Related
I should have a function that must return either a string of an error (through try / catch) or a different type T.
Example of such a function:
public T get()
{
T struttura;
try {
...
}
catch (Exception xcp) {
return xcp.Message;
}
...
return struttura;
}
There are ways to do this, but really consider if that's what you actually want. It is almost always better just to let the Exception bubble upwards into the calling code.
The first way is to use an out parameter.
public string get(out T result)
{
T struttura;
try{...}
catch (Exception xcp)
{
result = default(T);
return xcp.Message;
}
...
result = struttura;
return String.Empty;
}
The second way is to use a ValueTuple:
public (T, string) get()
{
T struttura;
try{...}
catch (Exception xcp){return (default(T), dexcp.Message);}
...
return (struttura, string.Empty);
}
The .net design guidelines https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/exception-throwing recommend never returning the exception as a return type. It’s always better design to throw the error and catch in the caller.
The guidelines also recommend that if you don’t want to throw the error that you can follow the TryParse pattern https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions-and-performance#try-parse-pattern. Typically you provide both methods, Get and TryGet. The presence of the Try method should indicate to callers that Get will throw exceptions but TryGet won’t. The TryGet also returns a Boolean if the operation was successful, allowing you to handle negative cases without using a try/catch block on the caller.
I suggest TryGet signature:
public bool TryGet(out T struttura) {
try {
...
struttura = ...
...
return true;
}
catch (Exception xcp){
struttura = default(T);
return false;
}
}
Usage:
if (TryGet(out var myStruct)) {
// succeeded, myStruct is returned struttura
}
else {
// failed
}
Or either do not catch exceptions at all or re-throw exception as custom one:
public T Get() {
try {
...
return struttura;
}
catch (Exception xcp) {
throw new MyException("My message", xcp);
}
}
Usage:
try {
myStruct = Get();
}
catch (MyException e) {
// Failed, e.Message for message
Console.WriteLine(e.Message);
}
Finally, you can mechanically combine value and message and return named tuple:
public (T value, string message) Get() {
try {
...
return (struttura, null);
}
catch (Exception xcp) {
return (default(T), xcp.message);
}
}
Usage:
var result = Get();
if (result.message == null) {
// succceded with result.value
}
else {
// failed with result.message
}
How to overwrite delegated parameters
I do have a service with a method like the below:
public static IEnumerable<IntegracaoParoquia> GetMyStuffFromRepo(MainForm form, Decimal myId)
{
IEnumerable<MyStuffClass> stuffCollection = null;
using (var unitOfWork = new UnitOfWork())
{
try
{
unitOfWork.OpenConnection();
stuffCollection = GetRepo().GetStuff(myId, unitOfWork.GetConnection(), unitOfWork.GetTransaction());
}
catch (Exception ex)
{
unitOfWork.Rollback();
LogError(form, ex);
}
}
return stuffCollection;
}
but since a can end with dozen call like this I want to wrap them in a generic call like the below:
private static R CallMyRepoMethod<P, R>(MainForm form, P param, Func<P, IDbConnection, IDbTransaction, R> method)
{
R result = default(R);
using (var unitOfWork = new UnitOfWork())
{
try
{
unitOfWork.OpenConnection();
result = method(param, unitOfWork.GetConnection(), unitOfWork.GetTransaction());
}
catch (Exception ex)
{
unitOfWork.Rollback();
LogError(form, ex);
}
}
return result;
}
public static IEnumerable<IntegracaoParoquia> GetMyStuffFromRepo(MainForm form, Decimal myId)
{
return CallMyRepoMethod<Decimal, IEnumerable<MyStuffClass>>(form, myId, (x,y,z)=>GetRepo().GetStuff(myId, null, null) );
}
The problem is: I want to keep the using inside my delegate (and the provided connection and transaction) but due to the repository method signature. When (x,y,z)=>GetRepo().GetStuff(myId, null, null) is called it passes the null values instead of using the correct values from the delegate.
That's reasonable if you consider the using is not in the scope outside the delegate.
There's any way to get around it or do I need to rewrite it using invoke?
I have two identical methods, but one of them have return statement inside try catch
public void A(Guid agentId)
{
var agent = _agentsProvider.GetAgentById(agentId);
var updateCompletionSource = C(agentId);
try
{
var cacheEntry = UpdateAgentMetadataCacheEntry(agent, true, false);
updateCompletionSource.SetResult(cacheEntry);
}
catch (Exception e)
{
updateCompletionSource.SetException(e);
}
}
private Entry B(IAgent agent)
{
var updateCompletionSource = C(agent.Id);
try
{
var cacheEntry = UpdateAgentMetadataCacheEntry(agent, false, false);
updateCompletionSource.SetResult(cacheEntry);
return cacheEntry;
}
catch (Exception e)
{
updateCompletionSource.SetException(e);
return GetPreviousCacheEntry();
}
}
How to collect identical part and create new method with this part?
Unless GetPreviousCacheEntry could have problematic side-effects, it seems to me that you don't need method A at all.
Just call method B and ignore the return value if you're not interested in it.
As noted in comments, the methods aren't identical other than the return statements though - because they use a different second argument for UpdateAgentMetadataCacheEntry, and they have different parameters too (one has a Guid and one has an Agent). You could refactor this into:
private Entry B(IAgent agent, bool foo)
{
var updateCompletionSource = C(agent.Id);
try
{
var cacheEntry = UpdateAgentMetadataCacheEntry(agent, foo, false);
updateCompletionSource.SetResult(cacheEntry);
return cacheEntry;
}
catch (Exception e)
{
updateCompletionSource.SetException(e);
return GetPreviousCacheEntry();
}
}
... with a meaningful name for foo, obviously. I'll assume the difference in parameter type isn't a problem in reality.
Like Jon said, you don't need method A. Just add another parameter for boolean value.
public void A(Guid agentId)
{
var agent = _agentsProvider.GetAgentById(agentId);
AnotherA(agent, true);
}
private Entry B(IAgent agent)
{
return AnotherA(agent, false);
}
private Entry AnotherA(IAgent agent, bool a)
{
try
{
var cacheEntry = UpdateAgentMetadataCacheEntry(agent, a, false);
updateCompletionSource.SetResult(cacheEntry);
return cacheEntry;
}
catch (Exception e)
{
updateCompletionSource.SetException(e);
return GetPreviousCacheEntry();
}
}
I have exception handling code in every method for the below code for the bottom level methods
throw new Exception("The error that happens");
Is there any way I can avoid writing this code again and again in each method?
I am trying to write my own code and not using any log frameworks
private void TopLevelMethod()
{
try
{
SomeMethod();
}
catch (Exception ex)
{
// Log/report exception/display to user etc.
}
}
private void SomeMethod()
{
TestPartA();
TestPartB();
TestPartC();
TestPartD();
}
private void TestPartA()
{
// Do some testing...
try
{
if (somethingBadHappens)
{
throw new Exception("The error that happens");
}
}
catch (Exception)
{
// Cleanup here. If no cleanup is possible,
// do not catch the exception here, i.e.,
// try...catch would not be necessary in this method.
// Re-throw the original exception.
throw;
}
}
private void TestPartB()
{
// No need for try...catch because we can't do any cleanup for this method.
if (somethingshappens)
{
throw new Exception("The error that happens");
}
}
Only catch errors if you want to do something meaningful to them such as:
Wrapping the exception with a framework exception (e.g. SqlException. ADO.NET never passes you socket-level errors. It passes you a meaningful SQL error code)
Cleanup
Actually responding (e.g. retry, or insert default values)
Logging is almost never appropriate. The top level handler should log. Certainly not every method in the path should log. What a clutter for logs and for the code. Don't do that.
Simply don't swallow error information and let the error bubble out. That way there is no reason left to insert local logging code for errors everywhere.
If you prefer using Functional Programming like code style one way is to use callback error callbacks.
Example :
private void SomeMethod()
{
// do something
}
public bool Execute(Action act, Action<Exception> onErrorCallback)
{
var res = true;
try
{
act();
}
catch (Exception ex)
{
res = false;
onErrorCallback(ex);
}
return res;
}
And use Execute like this:
var successfull = true;
successfull &= Execute(SomeMethod, (ex) => { /* clean up */ });
successfull &= Execute(SomeMethod, (ex) => { /* clean up */ });
successfull &= Execute(SomeMethod, (ex) => { /* clean up */ });
successfull &= Execute(SomeMethod, (ex) => { /* clean up */ });
if (!successfull)
; // show user or something else
Graffito: Would you please give sample code example.Thankyou...
Your code refactored:
private void TopLevelMethod()
{
List<string> errors=new List<string>() ;
if (!SomeMethod(errors)) { /* Log/report errors/display to user etc. */ }
}
private bool SomeMethod(List<string> errors)
{
return TestPartA(errors) && TestPartB(errors) && TestPartC(errors) && TestPartD(errors);
}
private bool TestPartA(List<string> errors)
{
bool result = true ;
try
{
// Do some testing...
if (somethingBadHappens) { result=false; errors.Add("The error that happens"); }
}
catch (Exception ex) { errors.Add("Error in TestPartA: "+Ex.Exception.Message.ToString()) ; }
return result ;
}
private bool TestPartB(List<string> errors)
{
bool result = true ;
// Do some testing...
if (somethingBadHappens) { result = false ; errors.Add("The error that happens"); }
return result ;
}
Is it possible to pass parameters to a catch block?
Here is some example code:
try
{
myTextBox.Text = "Imagine, that could fail";
}
catch (Exception e)
{
MessageBox.Show(e.Message);
}
Can I pass the Textbox (myTextBox) now to my catch block if it would fail? smth. like that:
try
{
myTextBox.Text = "Imagine, that could fail";
}
catch (Exception e, TextBox textBox)
{
textBox.BorderBrush = Colors.Red;
MessageBox.Show(e.Message);
}
How I would do that?
No it's not possible by standart.
What you can do, is to define your custom exception and assign parameters there, for example:
public class MyCustomException : Exception
{
public string SomeAdditionalText {get;set;}
....
//any other properties
...
}
and inside the method which raises an exception raise your own MyCustomException
You only catch a single thing, which in C# must be an Exception. So not directly. However! If the Exception were, say, a custom SomethingSpecificException, then you could make that information available on e.SomeProperty.
public class SomethingSpecificException : Exception {
public Control SomeProperty {get;private set;}
public SomethingSpecificException(string message, Control control)
: base(message)
{
SomeProperty = control;
}
...
}
Then at some point you could:
throw new SomethingSpecificException("things went ill", ctrl);
and
catch(SomethingSpecificException ex) {
var ctrl = ex.SomeProperty;
....
}
don't know what you want to achieve, but in the catch block you can access any UI element, as you do in the try block. So for me there is no point of defining an additional parameter in the catch block.
Next to the possibility to use custom exception to distinguish what's going on:
try
{
myClass.DoSomethingThatCouldThrow();
myClass.DoSomethingThatThrowsSomethingElse();
myClass.DoAnotherThingWithAThirdExceptionType();
}
catch(FirstSpecialException ex)
{
// Do something if first fails...
}
catch(SecondSpecialException ex)
{
// Do something if second fails...
}
You could also put every statement into its own exception block. This would make your code quite lengthly, but is maybe the only possibility if you can't change the class to throw any special exception.
try
{
myClass.DoSomethingThatCouldThrow();
}
catch(InvalidOperationException ex)
{
// Do something if it fails...
}
try
{
myClass.DoSomethingThatCouldThrow();
}
catch(InvalidOperationException ex)
{
// Do something if it fails...
}
try
{
myClass.DoAnotherThingWithAThirdExceptionType();
}
catch(InvalidOperationException ex)
{
// Do something if it fails...
}
Due to the fact, that this last, looks a little bit like repetitive code, we could maybe put it into some method with the following body:
public void TryCatch<ExceptionT>(Action tryMethod, Action<ExceptionT> catchMethod)
where ExceptionT : Exception
{
// ToDo: ArgumentChecking!
try
{
tryMethod();
}
catch(ExceptionT ex)
{
catchMethod(ex);
}
}
Which could you then call with:
TryCatch<InvalidOperationException>(
() => myClass.DoSomething(),
(ex) => Console.WriteLine(ex.Message));