|
Indeed, where it's appropriate, a simple check can often save time. Ultimately, as you progress, you end up building a handy set of utility methods that you can use, for instance here's a simplified version of a file create that you could use:
public static FileStream TryCreateFile(string fileToCreate)
{
string directoryName = Path.GetDirectoryName(fileToCreate);
if (!Directory.Exists(directoryName))
Directory.CreateDirectory(directoryName);
return File.Create(fileToCreate);
}
modified 23-Nov-11 15:33pm.
|
|
|
|
|
How does that save time? Delete will check for the existence of the file a second time.
Edit: Or is that just a bad example?
"If the file to be deleted does not exist, no exception is thrown."
modified 23-Nov-11 15:20pm.
|
|
|
|
|
It was actually a bad example - I'll update it with the example I was actually thinking of.
|
|
|
|
|
I'm afraid this isn't your day; you failed at improving the example.
Directory.CreateDirectory() does nothing when the folder already exists, so there is no point checking first.
|
|
|
|
|
Actually, in this particular case, there is - the IL is slightly different internally, and it saves clock cycles on the test in CreateDirectory. That's the reason it's in. The important part is actually the second part - hence the point of the example.
|
|
|
|
|
Ah. I never looked at the IL, I was assuming they were smart enough to make the test inside CreateDirectory() as efficient as the one inside Exists().
|
|
|
|
|
Why do I feel the need to go "Helloooooo. Microsoft."?
|
|
|
|
|
I don't know. Besides, I prefer How questions over Why questions any day.
|
|
|
|
|
Wouldn't be so handy if you'd use it to clear a folder. If you recently fetched the folders' contents, chances are that the files still exist.
Bastard Programmer from Hell 
|
|
|
|
|
Pete, this is good solid code (I'd expect no less from you), but in a way I can see this as a bit of a diversion from the original topic: error handling and Try/Catch.
In your code, yes, a Directory will be created, if none exists, but, what about the case it's an error ... for this particular application ... if the user is trying to save a file to a Directory that does not exist ?
And, what about the case where the Directory exists, but is read-only ?
Should code like this be "throwing" errors ? And what, if the code "throws," should be "catching them." And, as Abbott said to Costello: "Who's on first ?"
best, Bill
"... Sturgeon's revelation. It came to him that Science Fiction is indeed ninety-percent crud, but that also—Eureka!—ninety-percent of everything is crud. All things—cars, books, cheeses, hairstyles, people and pins are, to the expert and discerning eye, crud, except for the acceptable tithe which we each happen to like." early 1950's quote from Venture Sci-Fi Magazine on the origin of Sturgeon's Law, by author Theodore Sturgeon: source Oxford English Dictionary on-line "Word-of-the-Day."
|
|
|
|
|
Bill, sorry for the delay in replying. To answer your unspoken question, yes and no - the code was answering the premise that exception handling should not be relied upon when a simple check can solve the issue. So, what is the error we're coping with in this example? It's the fact that you can't write a file into a directory until that directory exists.
The other side here, is the fact as you've rightly pointed out, that this doesn't address all the cases that can be tested for. In my defence, I wrote this as a cut-down sample in the CP editor as an example only, but you are right, there are many other conditions that could be catered for. The point is really two-fold, if you create a utility API to handle the conditions that you can test for (rather than catch as an exception) then you have given yourself a real advantage when you come to write your production code. No, you won't get rid of exception handling altogether, but you won't be relying on it to cope with conditions that could easily have been tested for.
So, why do I advocate this? Well, exception handling is meant to indicate something that you couldn't reasonably predict and cope with. The mark of a good application is one that doesn't surprise users, so I'm either going to have to do lots of try/catch (and then cope with the failure before triggering the condition in the try/catch again), or I can put something in place to cope with the error before it occurs and make an intelligent decision about coping with the problem.
I hope this somewhat rambling post conveys some of what I was trying to get across.
|
|
|
|
|
mjackson11 wrote: Is there a better way to do this than having a block in each method?
Yup, you can hook an event that catches all unhandled exceptions[^]. There you can log it, without having the need for a try-catch everywhere.
Log everything you encounter, and handle those using try-catch blocks; some will be bugs, some will be exceptions that need a) user interaction (file in use, database dead), b) no user interaction. Handle what you can and log everything.
Bastard Programmer from Hell
|
|
|
|
|
That is a last best effort rather than being a general solution because the AppDomain will then exit (or application will exit at the top level.)
|
|
|
|
|
That's the idea with an unexpected exception; your application is in an unknown state, and hence, should terminate.
Bastard Programmer from Hell
|
|
|
|
|
I don't see anything in your original post that suggested it was only applicable for "...unexpected exception; your application is in an unknown state".
Most exceptions will not fall into that category. In general your suggestion is not applicable for exceptions. And nothing I see in the OPs posts suggests it is applicable to the OP.
|
|
|
|
|
My rule of thumb, I never catch an error I can't handle. And I never try something when there is an associated way to guarantee success. There are some people that clamor about correct code causing missed deadlines. Anecdotaly, successful programmers never complain about how much time it takes to write code correctly.
|
|
|
|
|
Hear hear!
"If you don't have time to do it right, when will you have time to do it over?"
|
|
|
|
|
It depends on the situation.
1. If it is an all-good-or-not situation, then it deserves a single overall try-catch.
2. If you want to extract as much as possible, then you need very granular error checking (if possible) or try-catching (if no error peeking is possible).
3. And if you can't handle the exception(s), then it falls back to either #1 or #2 anyway.
|
|
|
|
|
mjackson11 wrote: Is there a lot of overhead associated with these?
Not unless there are in fact a lot of exceptions.
mjackson11 wrote: Is there a better way to do this than having a block in each method?
That depends on what the application does and what you do in the block.
If you have a server that runs 24x7 and moves data from one remote source to another then sometimes there will be connection failures. In a case like that then the it must catch exceptions that originate from communication problems and continue.
If it is a console app that runs either pass/fail by a human and they are not supposed to run it unless everything is already working then catching an exception is optional. Maybe friendly but also an extreme case.
If the app needs to handle 3 sequential cases and all must pass then you must handle exceptions so that you can take some sort of action if step 3 fails after the first two succeeded.
When I write servers I catch almost everything so I can log it.
And so on...
|
|
|
|
|
Can you please post a piece of your code in a try catch block?
|
|
|
|
|
I have heard that you can use WMI to check the status of services running on another machine, and even to start/stop them.
Anyone have any experience with this? Exmaples would be great.
Thanks
Everything makes sense in someone's mind
|
|
|
|
|
Try here[^] and here[^].
I have personally been experimenting with WMI recently, myself. Here at work, we have a network set up. However, I cannot seem to get remote access via WMI. I get "Access denied" messages, though I think it is due to domain security policy issues which are out of my hands. I have not tried it at home yet.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Do you have any code you can share?
Everything makes sense in someone's mind
|
|
|
|
|
Hey i have made to forms. form 1 is the rich text file editor and the other is the find and replace.
in form1 i got 1 richtextbox and in form 2 i got 2 normal text boxes. i have changed all the modifier to public.
here the code i am using.
this is opening form2
private void findText_Click(object sender, EventArgs e)
{
Form2 frm2;
frm2 = new Form2();
frm2.ShowDialog();
}
here the code i am trying to use to find but it is not working
<pre lang="c#">RichTextBox frm1TB = ((Form1)this.Owner).txtDisplay;
int foundAt = frm1TB.Text. IndexOf(button1.Text);
hope someone can put me on the right path
|
|
|
|
|
Setting everything to public is bad, Form1 ought to expose some public interface (in the non-technical meaning of that word) that Form2 can use to communicate with it (which should be public or internal), for example a Find(string) method. (Since this is intrinsically a UI level functionality I think it's okay to do it with forms and in the UI code.)
Your immediate problem, I think, is that Form2 has no owner. Try
frm2.ShowDialog(this);
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
