|
I think what Luc means is: use the "code block" widget to presever your formatting on your original code. that would produce:
if(!mail)
{
if ((text != ""))
{
int indexofTO = text.IndexOf("to");
int indexofSLOT = text.IndexOf("Slot");
if (indexofSLOT < indexofTO)
{
...
}
}
}which I think you will agree is easier to read than:
if(!mail)
{
if ((text != ""))
{
int indexofTO = text.IndexOf("to");
int indexofSLOT = text.IndexOf("Slot");
if (indexofSLOT < indexofTO)
{
...
}
}
}Just putting the tags around your already posted code doesn't do that - try the "Preview" button when you add tags.
All those who believe in psycho kinesis, raise my hand.
|
|
|
|
|
Done, thanks. didnt realise.
|
|
|
|
|
right (actually this is the left side)
|
|
|
|
|
Much better, thanks.
Dictionary.Remove() removes an entry based on a key object, not the value. Even when two strings have equal content, they probably are different strings (unless they are simple reference copies, or both got interned).
Not sure what the easy solution is, I seldom remove things from a Dictionary.
[EDIT]
No, that is not it. A simple experiment shows Dictionary.Remove uses the default Comparer, which for strings compares the content.
Are you sure indexofTO + 2 is correct? How about indexofTO + 3?
[/EDIT]
modified on Monday, January 4, 2010 11:55 AM
|
|
|
|
|
Have you run this through the debugger? I bet the key is an empty string (or worse). If it can't find the key to remove, what exactly do you expect Remove() to do?
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
This line move media into a drive.
19/05/2009 10:53:40 Info Moved cartridge from Library 2 Slot 1 to Tape Drive 1
So I store the date time and the slot number(key) of when the media was moved into a drive, and when I see a removed media line, I used the date time from when it was moved out to show how long the media has been in.
I need to remove it from the dic because the media can be used again and I cant have duplicate keys.
FYI, there can be load of media being used at once, which I why I need to store this information.
An example of the data im reading in
19/05/2009 17:50:58 Info Moved cartridge from Library 2 Slot 4 to Tape Drive 1
19/05/2009 17:51:00 Info Moved cartridge from Library 2 Slot 8 to Tape Drive 2
19/05/2009 17:55:15 Info Moved cartridge from Library 2 Tape Drive 1 to Slot 4
19/05/2009 17:56:20 Info Moved cartridge from Library 2 Slot 1 to Tape Drive 1
19/05/2009 18:07:45 Info Moved cartridge from Library 2 Tape Drive 2 to Slot 8
19/05/2009 18:08:09 Info Moved cartridge from Library 2 Slot 7 to Tape Drive 2
20/05/2009 12:36:02 Info Moved cartridge from Library 2 Tape Drive 1 to Slot 1
20/05/2009 12:36:07 Info Moved cartridge from Library 2 Slot 6 to Tape Drive 1
20/05/2009 18:23:19 Info Moved cartridge from Library 2 Tape Drive 2 to Slot 7
|
|
|
|
|
So do any of the keys match the string you're building when you do your index math? That was my point.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
When I step through with the debugged. "Slot 1" is stored as the key in the dic and the on the loop that goes through to remove it the string key is also Slot 1.
|
|
|
|
|
Paul Harsent wrote: to remove it the string key is also Slot 1.
I don't think so, I expect it is " Slot 1" with a space.
|
|
|
|
|
Well, one thing that stands out to me is that the way you construct your key value on the Add and Remove is not symmetric.
string key = text.Substring(indexofSLOT, (indexofTO - indexofSLOT - 1));
string key = text.Substring((indexofTO + 2));
The key you use to Add has to match the key you use to Remove.
|
|
|
|
|
The reason for this is because the location of the key is different for loading and unloading.
19/05/2009 10:53:40 Info Moved cartridge from Library 2 Slot 1 to Tape Drive 1 //Load
19/05/2009 11:28:05 Info Moved cartridge from Library 2 Tape Drive 1 to Slot 1 //Unload
|
|
|
|
|
I understand the reason for it. I don't think your implementation is right. I think that you are off by 1 on your index in the second case so you end up with the wrong key value. If I am right, you are including a leading space in the key.
I am willing to be proved wrong, however, because that is just off the top of my head without trying it to check.
|
|
|
|
|
I feel very stupid. I was checking for the following space and having looked at the code for so long didnt see the lead space.
Thanks very much.
|
|
|
|
|
When you use
string key = text.Substring((indexofTO + 2));
the Substring method returns all the remaining text in the string starting from the supplied index. If you feel that the index position is correct try supplying a length parameter or verify there is no funky data at the end of the string. I've seen cases where odd characters have been thrown onto the end and caused me all kind of headaches especially when they are non-visual characters that most text editors won't render (like a Vertical Tab, ascii 11?). I recommend stopping at the above line in the debugger and checking all characters from indexofTO + 2 thru text.Length - 1 in the Watch window; check each individual character position and see if it contains the expected data.
Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
|
|
|
|
|
I am testing a c# application and one of the issues I am finding is the application throws unhandled exception error once in a while which leads to a debug and fix cycle.... Is there a way to get a list of all possible exceptions that can be thrown by the application and the line number where it can be thrown....
Regards
Ajay
|
|
|
|
|
Hope I'm not asking a dumb question but is the code you're executing within a try / catch block?
Second question is do you what is causing the exception yet?
|
|
|
|
|
JasonLee07 wrote: Hope I'm not asking a dumb question but is the code you're executing within a try / catch block?
Some of the code is ... and some is not.... The current approach is I test various features of the application until it pop-ups an unhandled exception after which the offending piece of code is encapsulated in an try {...} catch {...} block
What I was looking for is a formal method of getting a list of all possible code blocks which can throw an exception and performing a code review to ensure that all exceptions are properly handled.....
JasonLee07 wrote:
Second question is do you what is causing the exception yet?
I have root caused the exceptions which were triggered by my testcases.
|
|
|
|
|
try this:
try
{
.....
.....
}
catch(Exception ex)
{
......
......
}
|
|
|
|
|
edaindia wrote: Is there a way to get a list of all possible exceptions that can be thrown by the application and the line number where it can be thrown
Not that I know of. Well, that's a bit of a lie; you could loop through all the assemblies that are loaded, and list those classes that inherit from Exception.
The programmers should already be handling the errors that they can expect locally with a try-catch block, as has been noted a few times. The exceptions that remain should be handled in the "global exception handler". There's an event called ThreadException[^] that gets raised whenever there's some exception that didn't get handled by the try-catch blocks.
If you don't handle those, you'll get an ugly exception-screen. Now, you want a list of all the exceptions that can occur there? Well, everything that's derived from Exception - hence the suggestion to just log "everything" that triggers the ThreadException event.
Good luck
I are Troll 
|
|
|
|
|
Eddy Vluggen wrote:
Not that I know of. Well, that's a bit of a lie; you could loop through all the assemblies that are loaded, and list those classes that inherit from Exception.
Is there any way to do this?
Eddy Vluggen wrote: The programmers should already be handling the errors that they can expect locally with a try-catch block,
My concern was about finding those sections of code which should be within a try catch block, but are not.
If the exception was caught at the right location the programmer would have various options (e.g. abort,retry,ignore). Hence the emphasis on finding a formal way to identifying all code sections which can throw an exception and resolving them through a code review.
A global exception handler would be my last resort at the time of actual deployment.
Thanks for the reply....
|
|
|
|
|
edaindia wrote: Is there any way to do this?
Yes. Loop through all the assemblies in your domain, enumerate all classes within that assembly and check what they are made (derived) of.
Will that get you a list of all exceptions that can be thrown? Well, yes and no: it will give you a list of known exception-classes. Some classes might be generated at runtime, some are wrapped in global classes and only carry a cryptic number from the filesystem. Another point would be that you'd have some exceptions on that list that would be very rare. In other words, you'd end up with misleading information - preparing for StackOverflow-exceptions that simply never occur.
edaindia wrote: My concern was about finding those sections of code which should be within a try catch block, but are not.
With all respect, that's the programmers' own responsibility. You don't want an "on error resume next" system, and you don't want to force a user into deciding "ignore", "retry" and "cancel" for a StackOverflow. They'll get confused. I find myself often clicking the X-button in such a situation.
edaindia wrote: A global exception handler would be my last resort at the time of actual deployment.
Make it the first resort, and log everything that happens. Followup on everything, untill they slowly die out.
You can't avoid falling down, there will always be an exception that you didn't cater for. Or worse, a method that fails without throwing an exception. You don't want a customer relying on a backup that failed silently!
Once that you know that there will be an unhandled exception, your best option is to divine a strategy to handle them. Ie, implement that global exception-handler, and follow up on those rare exceptions that could actually harm your clients.
Think about it; what you're suggesting is closed to the default behaviour of a .NET application. It makes sense to shut-down the application, since there's an exception. And there's no way that you're going to surround each and every method with a OutOfMemoryException - some things can be translated to a simple message from a global point.
edaindia wrote: Hence the emphasis on finding a formal way to identifying all code sections which can throw an exception and resolving them through a code review.
Sounds rather hostile. I suppose that you could make a tool that assists the programmer in identifying methods that throw known exceptions. You'll get a hint which exceptions might be thrown when you hover your mouse over a method. Ergo, it should be possible to highlight those lines with a plugin for Visual Studio.
In theory that is
I are Troll
|
|
|
|
|
edaindia wrote: a list of all possible exceptions
No.
FYI: The list of things that can go wrong in Windows would be infinite.
|
|
|
|
|
And more often than not, there's not a damn thing you can do about it.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Isn't that called StackOverflow?
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Just put a try/catch block around everything that could fail, and there you have it.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
