 |

|
You should never be trying to handle exceptions from the whole application in the same place (apart from a last ditch catch-all to put up a message and log a bug report).
In any individual operation, there should be only one or two possible exceptions that can be thrown. You should catch and handle them appropriately as close as possible to the site of the operation.
|
|
|
|

|
We divide our whole application into layers , tiers, components etc. for modularity of a functionality. Cant we have a whole layer just to handle exceptions. In that case if we know that an exception is not being handled properly we will know where to go instead of having to browse through the whole code looking for the pertinent error.
|
|
|
|

|
Basically you either handle the exception, you ignore it (maybe with a message), or you log it (or combination). If you are logging, then basically you are centralizing the handling of the exceptions. What do you expect to do if you try to centralize the exception handling. That would be extremely complex. There are a number of frameworks for logging. We use log4net: log4net Tutorial[^]
|
|
|
|

|
Exceptions are part of the layers where they serve the best purpose, not a layer by itself.
|
|
|
|

|
Handle the exceptions you know you can handle as close as possible.
If you have a place no exceptions can be allowed to escape from, catch the root exception type - this will also catch all derived exceptions. But do this catch last, after the exception types you have different handling for.
If all your exception handling does is log an error, you only need to capture the root type.
|
|
|
|

|
You should know the .NET framework well enough to know what exceptions a method throws. For example, opening a file may cause an exception if the file doesn't exist, etc. Why would you have an application level exception handler for that? The method that opens the file should pop up a message box saying the file was not found.
|
|
|
|

|
On Error Resume Next
SMACK ouch, owe that smarts!
Never underestimate the power of human stupidity
RAH
|
|
|
|

|
Phanindra261 wrote: When creating big applications(even medium apps) there are so many different kinds of exceptions that can come?
How to go about handling them?
Ideally by the following
1. Anticipate expected conditions that can result in errors. These of course vary by the area of the application/enterprise in which they appear.
2. Consider what the application/enterprise should do when those occur. This includes how or even if it should be logged.
3. Implement the code based on 1/2
4. Unit test the code of 3, including the exception generation
5. Besides the above boundary layers should ALWAYS assume that unexpected errors will occur. Those exceptions should be caught and logged once (not every layer.) Each layer must determine what the result is when an unexpected exception occurs and what the layer (or specific parts of the layer) do when an unexpected exception occurs.
As an example...
A database layer should always expect that communication errors will occur. There are various ways of dealing with this (which do not matter for this discussion) but they should still be expected. Even a clustered database solution can experience communication failure. Whether this is logged depends on how it is handled but even if the database layer is returning it as a result failure is should not log a stack trace, but just log it as a single error (db comm error.)
A database layer should not normally expect a SQL syntax error. That is something that should normally only occur during development or QA. So if it occurs one must log it. The database layer can handle this as a failed result.
|
|
|
|

|
I have this small feeling that we have more control on our application when we manually code it instead of using a code generator. Is it true?
If so then how often should we use a code generator and to what extent?
If not so then can someone guide me to a good place where I can learn about writing code generators?!
THANK YOU
SATYMEVAJAYATHE
|
|
|
|

|
I never use one, I write all my own code.
|
|
|
|

|
Even *.designer.cs files?
No more Mister Nice Guy... >: |
|
|
|
|

|
I have on occaision been known to remove them and do my own initialization control. The designer.cs files are handy though
|
|
|
|

|
And what one would do when decide to open designer of such a form? I would guess that they wouold come to you to punch you
I very often edit them but not remove them, so i guess I am not withbout sin. :p
No more Mister Nice Guy... >: |
|
|
|
|

|
They're not really generated code, they're code which is manually edited using a graphical IDE. That is, every line in a .designer.cs file is there because you set a property or clicked something in the graphical editor.
|
|
|
|

|
You do not wrote it yourself, ergo it's generated.
No more Mister Nice Guy... >: |
|
|
|
|

|
If you write everything from scratch, you will have more control by definition.
If you use a code generator you may (depending on the code generator) get better or more consistent code quality, and you will definitely save time.
|
|
|
|

|
What about the performance issues?
Will the code generator not weigh down the application?
Oh and is there any difference a code generator and a template (for an application)? Also is there a relation between the two?
|
|
|
|

|
All occasions I've seen and used code generation tools, that's been a build-time issue, not run-time. You run the tool to create code, which is included in the compiling and build of the software. As such, there's no performance penalty when running, although it can complicat the build process.
For instance, Microsoft has a tool that takes an XML file and creates an XML schema from it. This schema can then be run through the same tool which can generate C# classes to represent it. This means you don't have to hand code the classes needed to serialise the XML, but have used a code generation tool. Typically, you'd only do this when there's been a change in the XML schema, not every time you build the system.
I'm not entirely clear what you mean by template here? Do you mean the different application and library types you can pick from when creating a new project in Visual C#? Those templates are effectivel recipes used by the code generation tool to create the project and its initial files.
|
|
|
|

|
I very much dislike generated code. If you need so much code to accomplish something that you feel the need to generate it, there is a more fundamental problem that needs addressing, perhaps in the language or choice of technology.
I don't include code which is generated from a non-text editor, like WinForms designer files or WPF/Silverlight XAML. You're still in charge of that, it's just the text editor isn't your usual editing environment. But the abominations that Microsoft create for you when you communicate with a COM or WCF server are fairly clear indications that they need to provide better tools to access those technologies.
|
|
|
|

|
The more experienced a developer is, the less likely they are to use any kind of generator.
Snippets as templates will get used, but not generated code.
I wasn't, now I am, then I won't be anymore.
|
|
|
|

|
But is it not true that developers at entry level have to use a much more hands-on approach, whereas developers at a higher level will have to concentrate on the design of the application from an architectural point of view.
Also as you reach a higher level your responsibilities will increase. Will you use up more of your time by manual coding when you can save your time with a good code generator?
|
|
|
|

|
Phanindra261 wrote: a good code generator
When I first started out as a developer many years ago, I thought that a code generator was a time saver and a great idea. The more experienced I got, the more I realized that code generators end up costing more time than an experienced developer writing it right the first time. Troubleshooting code from a generator is very often far more time consuming.
I have mentored a few developers over the years and I always try to steer them away from using "the easy button" because you don't learn much in development without doing the work yourself. So all in all, I don't like generators at all and I've found that most seasoned developers have tended to come to the same opinion I have of them. Cheers.
I wasn't, now I am, then I won't be anymore.
|
|
|
|

|
What a load of rubbish, you should be using a code generator where it is a valid tool for the job. Coding up the DAL layer is just crazy, coding up the model is just as dumb. Generating code for VM or the VIEW is impossible.
Obviously we are using Silverlight but the code generator we use started life as a VB5 tool in the 90s, it is called ClassBuilder, I pinched it from the lead developer on that project and have rewritten it a dozen times. It does the CRUD stored procedures, the Model (based on a view of the table) and the DAL. Half a dozen click and I have my WCF written.
We tried writing something for the VM and the View but that is where the hand coding is required.
Never underestimate the power of human stupidity
RAH
|
|
|
|

|
Mycroft Holmes wrote: Coding up the DAL layer is just crazy
I disagree. In my opinion, DAL code that can be generated shouldn't exist at all.
|
|
|
|

|
What about your standard CRUD operations?
Never underestimate the power of human stupidity
RAH
|
|
|
|
|

|
It depends. I'm generally not a fan, but I'm old-school.
Something like Linq-to-SQL will generate SQL code for you; if you're no good at writing SQL, then using it may be of benefit; if you are good at writing SQL, it may not be. (I don't use it.)
Other than the WinForms designers, the only code generators I use are ones I wrote to perform certain tasks for me:
GenOmatic[^]
Implanting Common Code in Unrelated Classes[^]
|
|
|
|

|
suppose I have a class A, and the interfaces I1 and I2.
Interfaces I1 contains methods a,b
Interfaces I2 contains methods a,b,c and d
class A can implements I1 or I2 depending on how it is constructed.
Question, what is the best structure to organize it?
one solution is to create a base class for Class A which implements only I1, and make Class A derived implementing I2:
Class BaseA:I1
Class A: I2, BaseA
Do you know any smarter solution?
|
|
|
|

|
You should only use a base class where you want the exact same implementation in all derived classes.
A an interface is a contract (no implementation unlike an abstract class) I don't really see the problem. This works just fine:
public interface I1
{
void A();
void B();
}
public interface I2
{
void A();
void B();
void C();
void D();
}
public class ClassA : I1, I2
{
public void A()
{ }
public void B()
{ }
public void C()
{ }
public void D()
{ }
}
If you want differing implementations of A and B depending on whether usin I1 or I2 then use explicit declaration:
public class ClassA2 : I1, I2
{
void I1.A()
{ }
void I2.A()
{ }
void I1.B()
{ }
void I2.B()
{ }
public void C()
{ }
public void D()
{ }
}
You will now need to cast the instance to either I1 or I2 to have access to methods A or B, but you can mix it up and provide the default implementation:
public class ClassA2 : I1, I2
{
public void A()
{
(this as I1).A();
}
public void B()
{
(this as I1).B();
}
void I1.A()
{ }
void I2.A()
{ }
void I1.B()
{ }
void I2.B()
{ }
public void C()
{ }
public void D()
{ }
}
|
|
|
|

|
may be not clear my question:
I2 has "a" and "b" methods that are the same of I1
So I2:I1
But the class A not always is able to implement I2. It depend on the constructor used in A. If A is instantiated using a contructor, then A implement I2, otherwise only I1.
This is why I create a base class
So:
I2:I1
BaseA: I1
A:BaseA, I2
This is the herarchy, it works, but it looks a bit overkilling for the simple problem. I was only asking if there is a more elegant solution..
|
|
|
|

|
Why not make I2 and abstract class so that when I2's methods are not implemented by ClassA the default empty implementation will work. here is some sample code:
Note: Replace I2 with A2 and ClassA and ClassA2 are two possible versions you could have for ClassA
public interface I1
{
void A();
void B();
}
public abstract class A2 : I1
{
public virtual void C()
{
}
public virtual void D()
{
}
#region I1 Members
public abstract void A();
public abstract void B();
#endregion
}
public class ClassA : A2
{
public override void A()
{
}
public override void B()
{
}
}
public class ClassA2 : A2
{
public override void A()
{
}
public override void B()
{
}
public override void C()
{
}
public override void D()
{
}
}
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
|
|
|
|

|
Is there a plus in this design with respect my one?
|
|
|
|

|
Strictly talking from a designs standpoint - Yes there is.
You see when we have an interface we are saying that we are defining a contract and all the classes implementing this interface should implement this contract i.e. methods. We cannot then say that we need to selectively implement the methods.
The abstract class says that, I am providing a default implementation and the derived class is free to have his own IF it needs to.
So in your case you needed some functions to be implemented selectively and some mandatory so following the design principle, I moved the mandatory ones in the contract i.e. the interface and the optional ones in abstract class. and in this particular case the default implementation of optional methods is to do nothing.
I hope i am able to convey my thoughts clearly. Do let me know if not. I am also open to counter arguments as they will only enhance my learning. (counter arguments == brainstorming) i.e. always beneficial
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
|
|
|
|

|
TheGermoz wrote: class A can implements I1 or I2 depending on how it is constructed
This is a dead giveaway for poor design. Inheritance hierarchies are telling you what operations you can do on an object, and you should be able to tell from the type of something what you can do with it. That is, an instance of A should always be treatable as an I2, or never.
What you almost certainly want to do is:
interface I1 {
void A();
void B();
}
interface I2 : I1 {
void C();
void D();
}
class A : I1 {
public virtual void A() {}
public virtual void B() {}
}
class A2 : A, I2 {
public void C() {}
public void D() {}
public override void A() {
base.A();
}
}
|
|
|
|

|
yes this is my degign I propose, I was wandering if it is ok
|
|
|
|

|
This is good. +5.
P.S. We might do away with the interface containing the optional functions as these are not a part of the contract. Also we can make class A as abstract to make sure no one is able to create it directly as its only purpose is to facilitate default implementation for optional functions.
I tried to do this design this way. I would love to hear your opinion on it:
http://www.codeproject.com/Messages/4429095/Re-Design-Question.aspx[^]
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
|
|
|
|

|
Since we don't know what the interfaces or the class 'A' represent we can't be sure what the contracts needed are. But as the question has two interfaces in it, it seems likely that he needs both, and publicly instantiable classes that implement each.
Rahul Rajat Singh wrote: Also we can make class A as abstract to make sure no one is able to create it directly as its only purpose is to facilitate default implementation for optional functions.
I don't think that's true. The original question suggests that it is possible to construct an A which is fully functional but only supports the I1 operations, and that it's also possible to construct an A which additionally implements I2. That means you need a concrete class and a concrete subclass.
|
|
|
|

|
Is there a reason why you are using interfaces? Too many .NET programmers make the mistake of thinking they need to use interfaces everywhere. Just like any other technology/construct/etc., you should only use interfaces when appropriate.
Is anybody using your class external to your app?
Based on the information you provided in your post, your design should be:
class A
{
virtual void a();
virtual void b();
}
class B : A
{
virtual void c();
virtual void d();
}
why over complicate? KISS.
|
|
|
|

|
Yes really there is a reason, the example was a very simplify version of may real problem. Anyway I appreciate your answer
|
|
|
|

|
Make interface I1 an abstract class instead (A1) or just create the class, whichever makes more sense, and inherit from A1 when you implement I2. Probably no reason to have the interface and the base class A1
|
|
|
|

|
Yesterday I had one form inside another and was told to use background working thred to solve a problem. I was wondering if I might also need a background thread for another project (meaning library, not part of the main program). This other project handles nothing but analysis and will calculate many millions of algorithms a minute. Does this have its own thread or should I set this up in a background thread as well.
I appreciate any help.
Thanks in advance.
|
|
|
|

|
If it's not already using threading for the calculations and if the calculations may take some time, then it would probably be a good idea. If the calculations are quick, even if there are a lot of them, then it may not be needed IMO.
|
|
|
|

|
Here's what I've got:
public struct ItmAray
{
public string FieldName;
public int FieldIndex;
}
public struct dtlst
{
public ItmAray[] ItemArray = new ItmAray[128];
}
public dtlst[] DataList = new dtlst[128];
This is what I want:
DataList[x].ItemArray[y].FieldName = clbText;
DataList[x].ItemArray[y].FieldIndex = int.Parse(a);
This is what I'm getting:
an error: "cannot have instance field initializers in structs" from the dtlst structure: public ItmAray[] ItemArray = new ItmAray[128];
I believe the problem is the righthand side of the line.
But I can't figure out how to fix it.
Thanks!
|
|
|
|

|
KKW_acd wrote: righthand side of the line
You are correct. As the message says, you cannot initialize a field when it is first declared in a struct, all fields assume the default value for the type which in the case of an array is null. Initialization must be done in a constructor (however you cannot have a parameterless constructor for a struct either).
When to use a struct or a class can be complicated sometimes. I think your dtlst (horrible name by the way - why not DataList?) should most likely be a class. You will then be able to initialize the field as you wish.
Also, public fields are normally bad practice, make them private and use a property (getter only unless a setter is needed) to expose the field.
Edit: There's still a few things about this that don't feel right, but to fit your code and usage, this is a quick example of something that works. This is not meant to be doing your homework for you, but rather to point you in the correct direction and give you something to compare your code too:
public struct Item
{
private string name;
private int index;
public Item(string name, int index)
{
this.name = name;
this.index = index;
}
public string Name { get { return name; } }
public int Index { get { return index; } }
}
public class DataList
{
private Item[] items = new Item[128];
public Item[] Items { get { return items; } }
}
DataList[] dataLists = new DataList[128];
int listIndex = 0;
int itemIndex = 0;
string itemText = "Random text";
string indexText = "1";
dataLists[listIndex] = new DataList();
dataLists[listIndex].Items[itemIndex] = new Item(itemText, int.Parse(indexText));
modified 15 Nov '12 - 13:19.
|
|
|
|

|
Dave,
Thankyou!
That is exactly what I needed!
Also, I'm flattered that you think this is homework! I wish I was as young. I'm an old bit-twiddler from the DOS and Microprocessor days. I even remember watching man's first step on the moon on an Admiral B&W tv! - Live!
Thanks again!
|
|
|
|

|
No problem.
KKW_acd wrote: I wish I was as young
Ah, sorry!
KKW_acd wrote: old bit-twiddler from the DOS and Microprocessor days
Then, once you get used to C# you will find this a lot of fun, and in many ways, a lot easier. Gone are the days where variables and function names need to be short and cryptic, we can be alot more verbose now e.g. A date and time combined is a DateTime not dtm. We have a powerful framework that has the vast majority of the dirty/hard work done for us. Allocating and freeing memory is taken care of (in most situations), threading, callbacks etc are a breeze compared to the old days. Many, many other things too.
It still of course requires the same skills and dedication/perseverance but the curve is somewhat shallower.
|
|
|
|

|
KKW_acd wrote: I even remember watching man's first step on the moon on an Admiral B&W tv! - Live! Me too, although a different TV model.
One of these days I'm going to think of a really clever signature.
|
|
|
|

|
In your dtlst structure you cannot initialise the instance variable ItemArray automatically, as structs do not have default (parameterless) constructors. You would need to initialize the variable after you have created the struct(s), i.e after you create the DataList array.
It is explained more clearly here[^].
One of these days I'm going to think of a really clever signature.
|
|
|
|

|
The immediate error is what's in the message.
However, I suspect you didn't mean to create a struct here. A struct in C# is a value type, so wherever it is passed to a method, a copy is taken, and the initial version is not modifiable. However, the array within the struct will be modifiable and the array in the outside version of the struct will be updated! A struct containing references to reference types, like an array, is usually not what you meant to do.
I think you are trying to recreate the C++
typedef struct {
string FieldName;
int FieldIndex;
} ItmAray;
typedef struct {
ItmAray[128] ItemArray;
} DtLst;
DtLst[128] DataList;
But the arrays there are references: DtLst[100] is a reference to a DtLst, and passing it to a function will pass it by reference. In C# I think you want a class.
Also, fixed length arrays are generally not what you want in the modern world. I think what you actually want is
class Field {
string Name;
int Index;
}
class DataListItem {
List<Field> Fields;
}
List<DataListItem> DataList;
|
|
|
|

|
i want to automate a c# application with windchill can anyone guide me from where i should start??
|
|
|
|
 |