Is there such a possibility to process common project exeptions in one place when the project is a class library?
I want to avoid code repetition from all catches block
Related
I'm working on a huge C# + VB.NET solution that has about 210 projects.
Some developers have over time been using a method that only work in a specific context (HttpContext needs to be present) which means that Console Applications that somewhere in their calltree use this method, will fail.
Other than throwing an exception (which might break running solutions), is there a way to check if this context dependent method is called by a specific 'parent' ?
In Visual Studio it's possible to "Find All References", so i'm looking for some tool that could do this recursively to give me a list of eg: all projects that somehow call this broken code.
I'm working on a Visual Studio solution that currently has two projects in it (with more to come later). One project is a mature C#/Winforms application that I built last year (think of it as the prototype). The other one is a DLL that is going to do the same thing as the prototype but through a different application. I'd like to re-use code from the prototype (let's call the method in question SyncInvoices() ) in the DLL because the prototype code works perfectly b/c I've hammered the bugs out of it. The class that contains SyncInvoices is baked into the prototype application instead of being its own DLL.
I've added the class that contains SyncInvoices() to the DLL's project (as a linked file, since it already exists elsewhere in the solution). I can instantiate that class in the DLL project and call SyncInvoices() but the compiler throws errors related to GUI elements.
The problem is that SyncInvoices() has some-thread safe calls to the Prototype application's GUI in it, basically used to pass messages/errors back to the interface.
The DLL doesn't have a GUI, so it doesn't need to run that code. It still builds the rest of the methods in that class, even though they aren't used. Is there a way I can tell the compiler to ignore those lines when building the DLL? I'd rather not maintain two sets of nearly identical code, especially when the two projects are part of the same solution.
I thought about using #define/ #if blocks to partition off the code but I'm not sure if C# works that way-- most of the time I've seen those used is to keep debug code from ending up in production. If it is possible to tell the app to include/exclude code through #if blocks, how do I set the values?
Should I just bite the bullet and make a copy of the method without the offending code in it?
Without more specifics it's hard to give the correct answer, but I'd say generally you'd handle this with events. Whatever calls into the GUI are happening in the prototype, that would typically be some form of event, which you would subscribe to in the prototype when you instantiate your new class.
Are there any particularly problematic cases you could give more specifics on?
When creating Custom Exceptions is it best practice to make a separate class file for each and every Custom Exception, or append the Custom Exceptions to the end of the class file that they relate to, or create a file (eg. CustomExceptions.cs) and add the Custom Exceptions there?
One class per file is always a good rule.
The other basics:
Mark your exception as [Serializable]
Overload all the System.Exception constructors
Don't inherit from System.ApplicationException
Well ... I would say that you should follow the rule of one class per file, except in case if this exception is just for "internal" functionality in your class. Then you can make it declared inside the class. However, if exposed by any means to outside world, separate it from the class. This exposure could also be seen from the actual probability that this exception goes unhanded to the users of your class. In this case, I would also expose it and would not declare it inside.
As others have stated, one class per file rule is ideal. Another way to think of it, if you have a large application consisting of many modules, you will have multiple namespaces and it's important to keep the exceptions that a certain class method (or set of classes/methods) can throw within their respective namespaces. This makes the code more readable and the reasoning behind your custom exceptions easier to decipher for other developers ... Or for you in 6 months when you forgot why you made half of them :)
I am working on a C# project and want to make use of the UnhandledException event to catch any exceptions I may have missed in my project (hoping there won't be any but to be on the same side).
I make quite a bit of software so I want to make a class library that all of my projects will make use of so I want to have one function that does all of the initialisation stuff of all my projects without me having to copy and paste the code into each project to do the same work.
What I am wondering is if I have in the class library the unhandled exception event using the following code
AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.UnhandledException += new UnhandledExceptionEventHandler(currentDomain_UnhandledException);
Will the unhandled exception only be used from within the class library or will this event handle also be exeucted from any projects that the references the class library.
Thanks for any help you can provide.
Assuming that all of your projects are running in the same appdomain, this will work correctly. We have this exact code encapsulated in a common DLL that is shared among numerous applications.
An additional suggestion: if this is used in Windows Forms applications, you probably also want to add a handler for System.Windows.Forms.Application.ThreadException. This serves as a backstop when, for example, someone forgets to add exception handling to a control event.
It is possible to load an assembly into a different application domain, but as long as you load the assemblies (like class libraries) into the current application domain this will handle the exception.
Relationship between application domains and assemblies:
http://technet.microsoft.com/en-us/subscriptions/index/43wc4hhs(v=vs.80).aspx
For instance, Assembly.LoadFile() or Assembly.Load() will load the assembly into the current app domain.
Your code could be creating a new app domain with:
AppDomain.CreateDomain(..) , then it could load assemblies into this domain, which would not be handled by your code.
If you reference libraries in your project they will be loaded into the current app domain.
I have an n-tier web application, and I want to catch a specific type of exception in every method coming from the DAL (Data access layer) and rethrow it as a new exception of a specific type.
There are many methods in my DAL, so I don't want to start wrapping each one with try/catch.
I think this is possible using the Exception Handling Application Blocks, but i couldn't find any good documentation of how to do this...
I'm not familiar with the previous versions of the application blocks neither.
Has your DAL repositories got an interface?
I would implement the interface using a decorator pattern.
All the decorator does catches the exception and then builds a new exception and throws that out to the upper tier
As a point of note, in our n-tiered applications we always let exception just get thrown naturally and catch them in once single place and log them. We only create specific exceptions if we absolutely have to and that would be rare enough.
The reason for this is maintainability of code. Code can easily become unreadable when try/catches exist everywhere.