I currently have this class that another programmer in my team coded:
public static class SoapExecuter
{
private static readonly ILog logger;
public static Exception ExecuterException { get; private set; }
public static bool IsSoapException
{
get
{
if (ExecuterException == null)
return false;
return ExecuterException.GetType() == typeof(SoapException);
}
}
public static bool Execute(Action action)
{
ExecuterException = null;
bool passed = false;
try
{
action();
passed = true;
}
catch (SoapException se)
{
ExecuterException = se;
logger.log(se);
}
catch (Exception ex)
{
ExecuterException = ex;
logger.log(ex);
}
return passed;
}
}
This is not very idiomatic and I would like to change it to something that happens within the try...catch clause.
Is there a way to not violate DRY and still stay within the idioms the language offers?
Of course I can inherit from the SoapException and log it but I'll have to catch a SoapException and create a new exception object that wraps it and then throw it only to be silenced one level above.
Any idea guys?
Sounds like what you really want is not to handle that exception inside Execute at all. The responsibility for handling the exception seems to lie with the code that calls Execute.
Of course you can still catch it, store it in ExecuterException, log it, and then rethrow it using throw; — but the purpose of ExecuterException eludes me. It seems that you only need it for IsSoapException, which in turn is much better written as ExecuterException is SoapException anyway, which even takes care of nullness and subclasses.
I don’t think anyone can be of any further help than this without seeing the code that uses the code you posted. If that code queries ExecuterException only immediately after calling Execute, then you can (and should) probably just change it to a try/catch in that code. If it actually queries ExecuterException elsewhere, then you could consider having that code store the reference instead, but either way, it would mean that the code is pretty entangled spaghetti code and probably requires a major rewrite anyway.
(By the way, just to nitpick, the first of the two catch clauses in your code is completely redundant. If you remove it you get exactly the same behaviour — unless logger.log has a special overload for SoapException, but then you should probably restructure that too.)
Related
I have a class from a third-party assembly (so I can't edit it):
public class MyClass
{
private bool _loggedIn;
public void Login() {_loggedIn = true;}
public void Logout() {
if (!_loggedIn) throw new InvalidOperationException();
_loggedIn = false;
}
}
Now, suppose I have an instance of MyClass (for which I don't know _loggedIn), and I need call LogOut. Which of the following methods of avoiding a fatal exception will generally be faster? (any other method would be fine too):
To call LogOut, and if _loggedIn == false, just catch the exception
To use reflection to check that _loggedIn == true, and only call LogOut if so
It depends on the invariants you expect to see in your application.
1. If you expect to have a lot of MyClass having different state(logged in, logged off), then it is better to avoid overhead of exception (because exception is Exceptional situation) and use some specific public IsLoggedIn property (obviously to avoid Reflection) or some TryXxxxx-like methods.
And even if you can't modify the original code no one stops you from wrapping it:
public class MyWrappedClass
{
public Boolean IsLoggedIn {get; private set;}
private MyClass m_Log;
public MyWrappedClass ()
{
this.m_Log = new MyClass();
this.IsLoggedIn = false;
}
public void Log()
{
try
{
this.m_Log.LogIn();
this.IsLoggedIn = true;
}
catch
{
this.IsLoggedIn = false;
}
}
public void LogOut()
{
try
{
this.m_Log.LogOut();
this.IsLoggedIn = false;
}
catch
{
this.IsLoggedIn = true;
}
}
}
You could even go further and implement IDisposable interface with it to avoid manual LogIn-LogOut management:
public class MyWrappedClass
{
private class LogSessionToken : IDisposable
{
private MyWrappedClass parent;
public LogSessionToken (MyWrappedClass parent)
{
parent.LogIn();
}
public void Dispose()
{
parent.LogOut();
}
}
public IDisposable LogSession()
{
return new LogSessionToken (this);
}
// ...
}
And use it like
using (var logToken = wrappedInstance.LogSession)
{
// do the work.
} // No need to worry about manual LogOut
2. If you expect to use only few of MyClass in a proper fashion, then it would be a better idea to not handle exception at all - if something wrong happened then it is some programming error thus the program shall be terminated.
First, if your class doesn't expose at least a read-only property for LoggedIn, there sounds like a fairly large design flaw.
For speed, using reflection will generally be faster, particularly if you cache the FieldInfo or build a Func<bool> using System.Linq.Expressions. This is because Exceptions collect lots of debug information when thrown, including a StackTrace, which can be expensive.
As with anything, though, it is often best to test such operations, as there are sometime optimizations or other factors that may surprise you.
If the pattern if (CanFoo) Foo(); appears very much, that tends to imply very strongly that either:
A properly-written client would know when it can or cannot call Foo. The fact that a client doesn't know suggest that it's probably deficient in other ways.
The class exposing CanFoo and Foo should also expose a method which will Foo if possible and appropriate (the method should throw if unable to establish expected post-conditions, but should return silently if the post-conditions were established before the call)
In cases where a class one does not control should provide such a method but doesn't, the cleanest approach may be to write one's own wrapper method whose semantics mirror those the missing method should have had. If a later version of the class implements the missing method, changing one's code to use that implementation may be easier than refactoring lots of if (CanFoo) constructs.
BTW, I would suggest that a properly-designed class should allow calling code to indicate whether it is expecting a transition from logged-in state to logged-out state, or whether it wants to end up in logged-out state but it doesn't care how it gets there. Both kinds of semantics have perfectly legitimate uses; in cases where the first kind would be appropriate, having a LogOut method throw an exception if called on a closed session would be a good thing, but in cases where client code merely wants to ensure that it is logged out, having an EnsureLoggedOut method that could be invoked unconditionally would be cleaner than having to add extra client-side code for that purpose.
I'm working on a method which uses reflection to call another method. That "other method" can, however, throw an exception and I'd like to propagate that exception with it's original stack information and InnerException. That is simply because the method that uses reflection is not supposed to handle the exception, the caller should.
Here's a simplified version of the code:
public static bool Test() {
try {
return (bool) typeof(Program).GetMethod("OtherMethod").Invoke(null, null);
} catch(TargetInvocationException ex) {
ExceptionDispatchInfo.Capture(ex.InnerException).Throw();
}
}
public static bool OtherMethod() {
throw new InvalidOperationException();
}
That code obviously won't compile, since the Test method (according to the compiler) doesn't always return a value.
I could add a return false after the ExceptionDispatchInfo.Capture but I was wondering if there's a nicer way of achieving the same thing. Without writing the redundant return false.
I know it's kind of a nitpick question, but I can't help wondering. Plus, redundant code gives me an itch :P
There is one other option: instead of adding a redundant return false; you could add a redundant throw;.
You then don't need to make up a return value. (OK, not a big deal for a bool)
The simplest solution that doesn't give you redundant or duplicated code is to only put things inside your try that are actually going to throw. Creating your bool, assigning it false and returning it are all "safe" operations, so leave them outside the try.
public static bool Test()
{
bool returnValueOfInvoke = false;
try
{
returnValueOfInvoke = (bool)typeof(Program).GetMethod("OtherMethod").Invoke(null, null);
}
catch(TargetInvocationException ex)
{
ExceptionDispatchInfo.Capture(ex.InnerException).Throw();
}
return returnValueOfInvoke;
}
public static void OtherMethod()
{
throw new InvalidOperationException();
}
Is there any attribute that I can use, attached to the method definition, that will suppress any exceptions of a certain type originating in that method? e.g.
[SuppressException(typeof(TimeoutException))]
public void TroubleMethod()
{
}
So when there is a TimeoutException, it won't throw outside of TroubleMethod?
You can use exception handling around the entire method:
public void TroubleMethod()
{
try {
// ...
} catch(TimeoutException) {
// Throw away
}
}
I don't think an attribute that does what you describe exists, though. If you want the debugger to step through your method, you can always use [System.Diagnostics.DebuggerStepThrough()], but as for suppressing exceptions, I don't think that's possible.
You can use PostSharp to do some tricky instrumentation to add such attribute.
If you really want to do this, you can get a bit closer to your attribute-like syntax with:
static void SuppressException<TException>(Action a) where TException : Exception
{
try
{
a();
}
catch (TException) { }
}
public void TroubleMethod()
{
SuppressException<TimeoutException>(() => {
...
}
}
Not that I am aware of, but you can always do this:
public void TroubleMethod()
{
try
{
// silly code goes here
}
catch() { }
}
A bad idea in almost all circumstances, though sometimes acceptable (rare). Just make sure to leave a comment for future maintainers (this includes you).
you could use try-catch to catch the exeptions and just ignore it or better you could respond to that exeption
check out the reference
I am fully aware that what I am about to ask is not good practice... but:
Let's say I have a class containing a function that I want to always return a value, but store any exceptions that might occur for later processing. Something Like:
public Exception _error { get; set; }
public bool IsValid()
{
try
{
//do something here to cause exception
return true;
}
catch (Exception ex)
{
_error = ex;
return false;
}
}
Now that I have stored the exception, is it at all possible to throw the exception from an outside method while maintaining both the original stack trace and exception type?
throw _error; //lose stack trace
throw new Exception("", _error) //lose type
Thanks for looking or answering.
EDIT:
Thanks to some additional points, I realize that the below idea only takes away information and doesn't really add or simplify the situation. Thanks again to everyone.
After pondering Pieter's answer and comments, I'm now wondering if making a wrapper Exception class like the below could be a partial solution. This overrides as much of the exception as possible to make the New exception look like its innerexception, including the stacktrace.. dirty I know, but interesting:
public class ExceptionWrapper : Exception
{
private Exception _innerException;
public ExceptionWrapper(Exception ex) : base("", ex)
{
_innerException = ex;
this.Source = ex.Source;
this.HelpLink = ex.HelpLink;
}
public override string StackTrace
{
get
{
return _innerException.StackTrace;
}
}
public override System.Collections.IDictionary Data
{
get
{
return _innerException.Data;
}
}
public override string Message
{
get
{
return _innerException.Message;
}
}
public new Exception InnerException
{
get
{
return _innerException.InnerException;
}
}
}
No, this is not possible.
However, you normally solve this is by wrapping the exception in a new exception:
throw new MyException("Wrapper", _error);
This does maintain the stack trace of _error, but you do get a new exception. Your solution in your second example is the correct way of handling these cases.
Consider using reflection to create a wrapper exception of the correct type (Activator.CreateInstance) and calling the constructor that will accept the inner exception you have stored.
For example:
[Test]
public void test()
{
Exception ex = new ArgumentNullException();
Exception wrapped = (Exception)Activator.
CreateInstance(ex.GetType(), "wrapped", ex);
Type expectedType = typeof(ArgumentNullException);
Assert.IsInstanceOf(expectedType, wrapped, "Is ArgumentNullException.");
Assert.AreEqual(ex, wrapped.InnerException, "Exception is wrapped.");
}
Update
In order to mitigate the constructor issue, you could consider using the default constructor (should be there for an exception that follows design guidelines, but not mandatory) and then patching up the new instance by setting its fields via reflection.
I agree the approach is highly "meh" it's more an exploration of an idea. I wouldn't recommend it.
The exception design guidelines require a default constructor, so this sort of behaviour may go on in the framework somewhere anyway. Perhaps for some sort of icky serialization\deserialization of exceptions across some sort of communications boundary?
It seems that .net-4.5 added a new API for capturing stack/info about exceptions and rethrowing them in different contexts. This is called ExceptionDispatchInfo. It is useful if you find yourself needing more control over running tasks indirectly, like if you do manual thread management for jobs or Task does not exactly fit your needs. In your example, it should look like this:
public ExceptionDispatchInfo _error { get; private set; }
public bool IsValid()
{
try
{
//do something here to cause exception
return true;
}
catch (Exception ex)
{
_error = ExceptionDispatchInfo.Capture(ex);
return false;
}
}
/// <summary>Throw underlying exception if invalid.</summary>
public void AssertWasValid() => _error?.Throw();
Now, it doesn’t preserve the original caller. The displayed stack trace shows the calls from the original try block into the code in there, a statement breaking the original and new parts of the stack, and then the calls into ExceptionDispatchInfo.Throw() itself as the new part of the shown stack. This seems similar to how traces with async code look. If you care about the original caller, seems this won’t work. But if you care about getting the line/method that threw the exception, this should be sufficient.
I'm using Compact Framework 3.5 / VS2008. I'm getting really odd behavior with TypeLoadException. The following code throws this error. The reason is a problem with the database connection. However for some unknown reason this inner exception is lost and is not contained in the TypeLoadException.
try
{
settingsFromDb = SettingsFromDbManager.Instance;
}
catch (Exception ex)
{
throw ex; // BREAKPOINT HERE
}
If we look at the SettingsFromDbManager class below it can be seen that it is a simple singleton class. The database error is occurring in the Load() method. I haven't included this code in the sample. If I put a breakpoint at the position indicated in the sample below I can see a database error. Unfortunately if I put a breakpoint in the position indicated in the code above then all I get is the TypeLoadException with no inner exception. There is nothing to indicate that a database problem occurred. This is bad :( Does anyone know why this strange behavior could be happening??
Cheers
Mark
public sealed class SettingsFromDbManager
{
static readonly SettingsFromDbManager _instance = new SettingsFromDbManager();
SettingsFromDbManager()
{
try
{
Load();
}
catch (Exception ex)
{
throw ex; // BREAKPOINT HERE
}
}
public static SettingsFromDbManager Instance
{
get
{
return _instance;
}
}
.... more code ...
}
** Update **
Thanks very much for all the great suggestions and help!
Pierre I used the test class you so kindly wrote. Here's the code I called it with. It must be a quirk of the Compact Framework I guess because when I examined the exception it was TypeLoadException with no inner exception :(
try
{
Fail.Test();
}
catch (Exception ex)
{
var x = ex.ToString(); // BREAKPOINT HERE
}
I think VinayC is probably correct about the reason. This is all a bit beyond my knowledge. Not sure what to do now. I don't want to give up my Singleton classes - they are useful. I'm using the "fourth version" Singleton pattern from http://csharpindepth.com/Articles/General/Singleton.aspx. I haven't used them before but seemed like a good idea to share the same instance of some utility classes around the application rather than creating and disposing them numerous times. Performance is a big issue with the Compact Framework.
* Update *
WOO HOO! All I had to do was change the Singleton class as follows. It instantiates the class in the property getter. Now my exceptions bubble to the surface as expected :)
public sealed class SettingsFromDbManager
{
static SettingsFromDbManager _instance = null;
SettingsFromDbManager()
{
try
{
Load();
}
catch (Exception ex)
{
throw new Exception("Error loading settings", ex);
}
}
public static SettingsFromDbManager Instance
{
get
{
if (_instance == null)
_instance = new SettingsFromDbManager();
return _instance;
}
}
.... more code ...
}
From what I know, static constructors may run on a different thread (or more specifically on different call chain) - its a guarantee from runtime that they will be invoked before type is accessed. Exception in the static constructor will mark type as not usable for the app domain. When type is accessed, you will get an TypeInitializationException (as per documentation) but exception occurred within type constructor will not come as inner exception because its not on same call chain - for that matter static constructor might had been executed quite before. Only puzzle out here is TypeLoadException instead of TypeIntializationException as Hans has pointed out.
Edit: Here's the article that explains lazy/eager semantics of type initializers. Your code can be eager implementation (i.e. static constructor may get invoked even before first access to type field)
There is no good reason why the exception raised in the static constructor would not show up in your original call location. However, I don't understand why you do not get the System.TypeInitializationException instead, which should be the exception thrown in case your static constructor fails.
Here is a piece of sample code which throws System.TypeInitializationException with an inner exception set to the "failed" exception:
class Fail
{
static Fail()
{
}
Fail()
{
throw new System.Exception ("failed");
}
static readonly Fail instance = new Fail ();
public static void Test()
{
}
}
I would investigate further to understand why you are getting a TypeLoadException instead, which should occur when an assembly cannot be properly loaded or initialized (TypeLoadException Class in MSDN).