|
Hi all.
I've had a DataBase[^] that named Database1.mdf
After that VS2008 SP1 creates a DataSet in my Project, named Database1DataSet
Then I've created a TableAdapter[^].
Now I wanna update the DataBase with them ( DataSet & DataTable & TableAdapter ).
I used this code :
Database1DataSetTableAdapters.eventsTableTableAdapter eventsTableTableAdapte =
new WpfApplication1.Database1DataSetTableAdapters.eventsTableTableAdapter();
Database1DataSet.eventsTableDataTable eventsTableDataTable =
new Database1DataSet.eventsTableDataTable();
eventsTableTableAdapte.Fill(eventsTableDataTable);
var id = (from c in eventsTableDataTable.Distinct()
select c.id).Last();
id++;
DataRow newDataRow = eventsTableDataTable.NewRow();
newDataRow["event"] = "event" + id.ToString();
newDataRow["date"] = id;
eventsTableDataTable.Rows.Add(newDataRow);
eventsTableTableAdapte.Update(eventsTableDataTable);
eventsTableTableAdapte.Dispose();
eventsTableDataTable.Dispose();
But the changes not apply to the DataBase , Why ? 
What's wrong with it ?
Many thanks in advance.
|
|
|
|
|
Lets say I have a hypothetical class which does something and upon error throws exception as below:
public class Do
{
void DoSomething()
{
// do a few things
// do a few more things
if (SomethingWrong())
throw // some exception here
}
}
I understand I have the option to either create my own custom exception, throw the exception, or simply create a new Exception object and add my own message to it and link the inner exception to it.
My question is which of the above option is more ideal? Or should I throw ApplicationException?
Also in client code, which of the following is a better programming habit:
try
{
SomethingWhichCanThrowExceptionA();
SomethingWhichCanThrowExcepitonB();
// Some code here which does things and will not throw exception
}
Catch(ExceptionA)
{
// Recover
}
Catch(ExceptionB)
{
// Recover
}
Or:
try
{
SomethingWhichCanThrowExceptionA();
SomethingWhichCanThrowExceptionAPassed = true;
}
Catch(ExceptionA)
{
// Recover
}
if (SomethingWhichCanThrowExceptionAPassed)
{
try
{
SomethingWhichCanThrowExcepitonB();
SomethingWhichCanThrowExceptionBPassed = true;
}
}
Catch(ExceptionB)
{
// Recover
}
if (SomethingWhichCanThrowExceptionAPassed && SomethingWhichCanThrowExceptionBPassed)
{
// Some code here which does things and will not throw exception
}
Please shed some light on this or provide your own suggestions and how you do things.
|
|
|
|
|
Hi,
IMO and unless a pre-existing Exception type fits the bill accurately (as in NullReferenceException),
you should create your own Exception type, give it an appropriate name ending on "Exception" and
derive it directly or indirectly from Exception or better yet ApplicationException; even do consider a hierarchy of Exceptions.
The advantage is you (and the users of your class) can then catch your new exception type(s) without
catching more global Exceptions.
|
|
|
|
|
But if all I am doing is simply reporting a message with a more friendly message, does it make sense to create custom exceptions? For example,
RetrieveStudent(string id)
{
// Do a few things
if (Error)
throw new Exception("Failed to retrieve the student with id " + id);
}
And what about the 2nd question I had?
|
|
|
|
|
CodingYoshi wrote: simply reporting a message with a more friendly message
even then, it is good practice; it is up to you to decide whether you value the precise catching it allows.
CodingYoshi wrote: 2nd question
the latter: separate try-catch constructs offer better isolation, better readability.
in the former, if you want B to happen even when A fails, your recovery code in the catch block would have to duplicate some code from the try block, which is bad.
ultimately you could consider putting each of the try-catches in a separate method.
|
|
|
|
|
Exception handling is by definition about HANDLING an exception. When you want to display a friendly message, you are not handling anything. Handling an exception is for example retrying a connection to a remote machine after a timeout exception. This is real exception handling. Another form of exception handling is finding an alternative in case of disk I/O problem... writing on another disk or requesting the user to free some space for example.
Any other thing that you might want to do, like logging or displaying a message, should be placed at one single location within your application, potentially the application controller. This "application host" component (it can be your Program.cs as well...) is supposed to do something (log, display a popup, exit the application or close the form, or whatever you think may be appropriate). But it can terminate as well, it is up to you to decide when your application is stable, and when it is not.
Exception handling means what it says, you handle an exception when you can do something with it, otherwise you leave it going up the stack till it reaches the entry point.
JC
Jean-Christophe Grégoire
|
|
|
|
|
I understand the point is to handle the exception by retrying, trying an alternative etc. but I am talking about times when you can not recover from it and you throw it to the caller and hopefully the caller can fix the problem.
|
|
|
|
|
If you cannot handle the exception or add anything meaningful to it then don't catch it.
|
|
|
|
|
Exceptions generally match with their namespace and are thrown via their public members (although, a property should never throw an exception). You are not really supposed to make plenty of exceptions for the tons of different possible problems. Exception handling is really about exception handling. A public method in System.IO.File.Read() could for example throw a System.IOException , without more. Internally, you don't have to handle that at many levels, you just leave it going up till the public method that was called. In this public method, you may indeed have a problem because another component lower in the chain had a problem, for example a network problem during the Read operation. Well, yes, then you receive a System.NetworkException for example, you catch it and rethrow a new exception of type System.IOException with the original exception provided as "inner exception". This is the normal way of doing.
So, imagine that you create a new library ComicSoft.ZipUtilities , in the simplest case possible, you can think of one single custom exception for the whole assembly called ComicSoft.ZipUtilities.ZipUtilityException which could be thrown by any public method. And when you have to throw your custom exception because something else crashed, you just give the original exception as parameter when you instantiate it.
This is really the simple and academic case, exception handling and rethrow policies is a huge debat  Exception handling can be made much more elaborate, and exceptions should ideally be forseen to be technically useful. Forsee codes, categorize exceptions, find ways to help locating the problems etc... But in its simplest form, what you should do is one or more exception for public methods, depending on the different possible feedbacks that you think will need to provide. If you start doing that internally, then it really should be to use the exception type as condition to execute real handling.
Jean-Christophe Grégoire
|
|
|
|
|
CodingYoshi wrote: But if all I am doing is simply reporting a message with a more friendly message, does it make sense to create custom exceptions?
Yes, create the custom exception class. And I would suggest that instead of "a more friendly message" you provide a message that gives more context, that is more useful to the debugger, or the person reading the log file. It is very poor practice to be outputting exception messages to the user - There lies the potential for security breaches.
|
|
|
|
|
In answer to your second question, I'd suggest using the first style, which is more concise and clearer for readers. It clearly says "DoA(), DoB if A is successful, catch and handle A errors, catch and handle B errors". It's certainly cleaner IMO.
|
|
|
|
|
CodingYoshi wrote: create my own custom exception
Yes.
CodingYoshi wrote: simply create a new Exception object
Never create an Exception object. Only something derived from Exception.
CodingYoshi wrote: create a new Exception object and add my own message to it and link the inner exception to it.
Where is this other Exception object coming from that you are putting in the inner exception? it isn't in the code you showed.
Basically, create a custom exception class or use an existing specific exception if one exists. For example, I'll often create a DalException, or an excption for a specific part of the model in my application, e.g. a SalesException or BookingException. I won't create one for absolutely every exentuality, but I use them in logical groupings.
CodingYoshi wrote: Or should I throw ApplicationException?
I'm not a fan of the ApplicationException, it is too generic. You can derive from it if you want.
In terms of how much code to put in your try block, that depends on the individual situation.
If the two exceptions are distinct, as in your example, then I don't really see a problem with the first way you showed it. (i.e one try block.)
I would suggest that if the two method calls can potentially produce the same kind of exception and you need to differenciate which method call produced the exception then your second example would be best.
|
|
|
|
|
I want to be set the Default value of a property in a class to be serialized, i have found this is easy enough on simple types but i want to set the default values of some complex properties like
public class Script
{
...
[DefaultValue("Hello World")]
public string Name { get; set; }
//How do i do this?
[DefaultValue(...)]
public Information Info { get; set; }
...
}
I'm not to sure on how to do this any suggestions would be appreciated
Jordan.
|
|
|
|
|
[DefaultValue(typeof(ClassName), "ValueAsDisplayedInPropertyGrid")]
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
That doesn't work as the value in the property grid is just "Scripts.Information" is there anyway i can change this?
|
|
|
|
|
Have a look at the solution Mika suggested below. If that doesn't work for you - then you may need to get more in depth and use TypeConverters. I wrote an article here[^] a while ago about this. I didn't really explain the more advanced latter bits of the code in the article (I must get around to sorting that!) but you should be able to figure it out from the code.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
|
I come from VB. Now I’m trying to learn C++. Can someone help me find good tutorials for someone without a Visual Compiler? Im using Dev-C++ 4.9.7.0
|
|
|
|
|
|
this is C# forum.
I Love KongFu~
|
|
|
|
|
I come from VB. Now I’m trying to learn C++ now. Can someone help me find good tutorials for someone without a Visual Compiler? Im using Dev-C++ 4.9.7.0
|
|
|
|
|
I suggest you read the title of this forum, then go to the right forum.
Hint: there are at least 2 forums on C++ depending on your exact needs.
|
|
|
|
|
Hello,
I would like to call a method multiple times by a count. For example:
If count = 6 call method 6 times.
Thank you so much for the help.
RB
|
|
|
|
|
for[^]
You need to read very basic c# book.
|
|
|
|
|
1.
for(int i=0; i< count; i++) myPopularMethod(withPossiblySomeArguments);
2.
or create a delegate and an event; add the delegate count times to the event and call the event.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
