I want to use OnExceptionAspect from PostSharp. Want to know whether this aspect support Async methods or not?
Can anyone suggest links or sample code?
Thanks.
To enable full compatibility of OnExceptionAspect with async methods, you need to set the ApplyToStateMachine property to true, for example in your aspect's constructor.
[Serializable]
public class CustomAspect : OnExceptionAspect
{
public CustomAspect()
{
ApplyToStateMachine = true;
}
// ...
}
There's more information about using OnMethodBoundaryAspect with async methods in documentation and it is also applicable to OnExceptionAspect.
One important caveat is that you cannot change the exception's flow behavior in async methods. So, you can't, for example, ignore the exception being thrown, while you still can do some logging or processing on it.
Related
Is it possible to mock super class method call? I have seen many posts, but they are either irrelevant or using different testing framework.
Is it possible with easymock?
If not, what other framework would allow me to do it?
No it's not. And I don't think it is with other frameworks. That would required bytecode manipulation of the base class. So maybe Powermock but I'm not sure.
However, I have never needed to do that in 20 years. In general, it means a bad implementation of the template pattern.
So instead of something like
public void foo() {
// do stuff
super.foo(); // don't forget to call super
// do some other stuff
}
you better do
base class:
public void foo() {
doBeforeFoo();
// ... stuff that is in super
doAfterFoo();
}
and then you fill the holes in the child class
We have implemented a SonarQube-plugin with an extension that implements Decorator and deployed it to extensions/plugins.
Unfortunately, when triggering the sonar-analysis, the extension implementation is not called. Is there anything more that needs to be configured?
The implementation looks as simple as this:
public class MyPlugin extends SonarPlugin {
#Override
public List getExtensions() {
return Arrays.asList(MyExt.class);
}
}
#DependsUpon(DecoratorBarriers.ISSUES_TRACKED)
public class MyExt implements Decorator, BatchComponent {
#Override
public void decorate(Resource resource, DecoratorContext decoratorContext) {
Project project = decoratorContext.getProject();
Measure measure = new Measure();
measure.setData("abc");
decoratorContext.saveMeasure(measure);
}
#Override
public boolean shouldExecuteOnProject(Project project) {
return true;
}
}
If you're using SQ 5.2, Decorator does not work anymore. You have to move to the MeasureComputer interface instead.
The API is really unclear about this, and the #Deprecated annotation is misused IMHO (usually you first deprecate code, keep it working until it does not work anymore, then you just delete it... you don't deprecate code in order to inform people that it's not usable anymore...)
I guess that somebody at SonarSource forgot what code deprecation is about...
While a deprecated software feature remains in the software, its use may raise warning messages recommending alternative practices; deprecated status may also indicate the feature will be removed in the future. Features are deprecated rather than immediately removed, to provide backward compatibility and give programmers time to bring affected code into compliance with the new standard.
I am using version 4 of MVVM Light for Windows 8; it includes SimpleIOC. In various examples I sometimes see code to request an object based on SimpleIoc... and sometimes it is based on ServiceLocator...
Examples include:
userToken = SimpleIoc.Default.GetInstance();
mainVM = ServiceLocator.Current.GetInstance();
What is the difference between using SimpleIoc.Default.GetInstance and ServiceLocator.Current.GetInstance?
If there is no difference, does ServiceLocator just let me to have an option to change my mind about what IOC library I want to use? Does ServiceLocator just provide an additional layer of abstraction that is irrelevant if I am satified with SimpleIoc; or, does ServiceLocator perform some other useful magic that is not obvious to we IOC novices?
Thanks for the insight!
In your ViewModelLocator class you probably have the following line of code:
public ViewModelLocator()
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
SimpleIoc implements the IServiceLocator interface, which means that the ServiceLocator will use it as a DI source when invoked.
Edit:
OK, people want the "full fat and don't spare the cream" answer. Here we go!
ServiceLocator is basically a shell. The code for Service locator is:
public static class ServiceLocator
{
private static ServiceLocatorProvider currentProvider;
public static IServiceLocator Current
{
get
{
return ServiceLocator.currentProvider();
}
}
public static void SetLocatorProvider(ServiceLocatorProvider newProvider)
{
ServiceLocator.currentProvider = newProvider;
}
}
Yup, that's it.
What's ServiceLocatorProvider? It's a delegate that returns an object that implements IServiceLocator.
SimpleIoc Implements IServiceLocator. So when we do:
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
We put our SimpleIoc object into the ServiceLocator. You can use either of these now because whether you call ServiceLocator.Current or SimpleIoc.Default you're returning the same object instance.
So, is there any difference between
userToken = SimpleIoc.Default.GetInstance();
mainVM = ServiceLocator.Current.GetInstance();
?
Nope. None. Both are singletons exposing a static property that is an implementation of IServiceLocator. As mentioned above, you're returning the same instance of object that implements IServiceLocator regardless of which you call.
The only reason why you might want to user ServiceLocator.Current.GetInstance() rather than SimpleIoc.Default.GetInstance() is that at some point in the future you may change DI containers and, if you use ServiceLocator, you won't have to change your code.
Based on Mr. Bugnion's article on MSDN (in the section, "Various Ways to Register a Class"), I am presuming interchangeability of IoC providers is the one and only reason for using ServiceLocator.
As #FasterSolutions stated, SimpleIoc implements IServiceLocator, so I suspect the opposite to your statement about abstraction layers is true. I think you should use ServiceLocator, but this is without empirical evidence; maybe someone can prove me wrong (?)
I posted this on the TypeMock forums, but am too impatient to wait for a response there. This is a very n00b question.
I'm trying to set up a fake IContainer. Here's what I have:
var container = Isolate.Fake.Instance<IContainer>();
var program = Isolate.Fake.Instance<IProgram>();
Isolate.WhenCalled(() => container.Resolve<IProgram>()).WillReturn(program);
(IProgram is an interface in my code).
When I try to run this code, I get an Autofac exception: "The requested service MyApp.IProgram has not been registered."
How could this exception be thrown though? I'm not actually calling container.Resolve(), right? I'm just setting it up to return a fake IProgram.
Unrelated background info: I'm trialing TypeMock because Autofac uses extension methods extensively and Moq won't mock them.
A couple of things that may help - first, you can mock Resolve() calls with Moq by setting up IComponentContext.Resolve(), which all of the extension methods delegate to.
Second, Autofac is designed so that you shouldn't have to use its interfaces from your components. See for examples:
http://nblumhardt.com/2010/01/the-relationship-zoo/
http://code.google.com/p/autofac/wiki/TypedNamedAndKeyedServices and
http://code.google.com/p/autofac/wiki/DelegateFactories
Where you need to use (and thus mock) IContainer or a similar interface, you can probably do the same thing using the Func, IIndex and/or Owned relationship types.
Hope this helps!
Nick
Unfortunately, there's currently a bug in Isolator, which prevents faking Autofac containers. We're working to resolve it as soon as possible.
In the mean time, is there a reason you're not using Autofac as intended, meaning have it return a fake instance, such as:
[TestFixture]
public class TestClass
{
private ContainerBuilder builder;
private IContainer container;
[SetUp]
public void SetUp()
{
builder = new ContainerBuilder();
}
[Test, Isolated]
public void Test1()
{
var fakeProgram = Isolate.Fake.Instance<IProgram>();
builder.RegisterInstance(fakeProgram).As<IProgram>();
container = builder.Build();
var program = container.Resolve<IProgram>();
Assert.AreEqual(fakeProgram, program);
}
}
I want to handle different types of docs the same way in my application
Therefore:
I have a generic interface like this.
public interface IDocHandler<T>where T: class
{
T Document { get;set;}
void Load(T doc);
void Load(string PathToDoc);
void Execute();
void Execute(T doc);
}
And for different types of documents I implement this interface.
for example:
public class FinanceDocumentProcessor:IDocumentHandler<ReportDocument>
{}
public class MarketingDocumentProcessor:IDocumentHandler<MediaDocument>
{}
Then I can do of course something like this:
IDocumentHandler<ReportDocument> docProc= new FinanceDocumentProcessor();
It would be interessting to know how I could inject T at runtime to make the line above loosly coupled...
IDocumentHandler<ReportDocument> docProc = container.resolve("FinanceDocumentProcessor());
but I want to decide per Configuration wether I want to have my FinanceDomcumentProcessor or my MarketingDocumentProcessor... therefore I would have to inject T on the left site, too ...
Since I have to use c# 2.0 I can not use the magic word "var" which would help a lot in this case... but how can I design this to be open and flexible...
Sorry for the misunderstanding and thanks for all the comments but I have another example for my challenge (maybe I am using the wrong design for that) ...
But I give it a try: Same situation but different Explanation
Example Image I have:
ReportingService, Crystal, ListAndLabel
Three different Reporting Document types. I have a generic Handler IReportHandler<T> (would be the same as above) this Handler provides all the functionality for handling a report Document.
for Example
ChrystalReportHandler:IReportHandler<CrystalReportDocument>
Now I want to use a Framework like Unity (or some else framework) for dependency injection to decide via configuration whether I want to use Crystal, Reportingservices or List and Label.
When I specify my mapping I can inject my ChrystalReportHandler but how can I inject T on the left side or in better word The Type of ReportDocument.
IReportHandler<T (this needs also to be injected)> = IOContainer.Resolve(MyMappedType here)
my Problem is the left Site of course because it is coupled to the type but I have my mapping ... would it be possible to generate a object based on Mapping and assign the mapped type ? or basically inject T on the left side, too?
Or is this approach not suitable for this situation.
I think that with your current design, you are creating a "dependency" between IDocumentHandler and a specific Document (ReportDocument or MediaDocument) and so if you want to use IDocumentHandler<ReportDocument or MediaDocument> directly in your code you must assume that your container will give you just that. The container shouldn't be responsible for resolving the document type in this case.
Would you consider changing your design like this?
public interface IDocumentHandler
{
IDocument Document { get; set; }
void Load(IDocument doc);
void Load(string PathToDoc);
void Execute();
void Execute(IDocument doc);
}
public class IDocument { }
public class ReportDocument : IDocument { }
public class MediaDocument : IDocument { }
public class FinanceDocumentProcessor : IDocumentHandler { }
public class MarketingDocumentProcessor : IDocumentHandler { }
If I understand you correctly, you have two options.
if you have interface IDocHandler and multiple classes implementing it, you have to register each type explicitly, like this:
container.AddComponent>(typeof(FooHandler));
if you have one class DocHandler you can register with component using open generic type
container.AddComponent(typeof(IDocHandler<>), typeof(DocHandler<>));
then each time you resolve IDocHandler you will get an instance of DocHandler and when you resolve IDocHandler you'll get DocHandler
hope that helps
You need to use a non-generic interface on the left side.
Try:
public interface IDocumentHandler { }
public interface IDocumentHandler<T> : IDocumentHandler { }
This will create two interfaces. Put everything common, non-T-specific into the base interface, and everything else in the generic one.
Since the code that you want to resolve an object into, that you don't know the type of processor for, you couldn't call any of the T-specific code there anyway, so you wouldn't lose anything by using the non-generic interface.
Edit: I notice my answer has been downvoted. It would be nice if people downvoting things would leave a comment why they did so. I don't care about the reputation point, that's just minor noise at this point, but if there is something seriously wrong with the answer, then I'd like to know so that I can either delete the answer (if it's way off target) or correct it.
Now in this case I suspect that either the original questionee has downvoted it, and thus either haven't posted enough information, so that he's actually asking about something other than what he's asked about, or he didn't quite understand my answer, which is understandable since it was a bit short, or that someone who didn't understand it downvoted it, again for the same reason.
Now, to elaborate.
You can't inject anything "on the left side". That's not possible. That code have to compile, be correct, and be 100% "there" at compile-time. You can't say "we'll tell you what T is at runtime" for that part. It just isn't possible.
So the only thing you're left with is to remove the T altogether. Make the code that uses the dependency not depend on T, at all. Or, at the very least, use reflection to discover what T is and do things based on that knowledge.
That's all you can do. You can't make the code on the left side change itself depending on what you return from a method on the right side.
It isn't possible.
Hence my answer.