|
hi,
Please little bit more clear.
**************************
S r e e j i t h N a i r
**************************
|
|
|
|
|
I just posted this very same answer in the VB.NET Forum today. Here's[^] the link. I know, I'll get flamed for this, but I hate writing the same code twice...
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi,
I pretty bad in vb.net. Is it possible to show in in C#.net.;)
**************************
S r e e j i t h N a i r
**************************
|
|
|
|
|
I validate all input data using a Validation class with functions like:
IsAlpha, IsAlphaNumeric, IsEmail, Lenght, IsNumber
Normally I make the validation in the Click Event of a form, and then I show the errors using an error control.
Is there a better way to validate input data? And for what are the events "Validated" and "Validating"?
Thanks.
|
|
|
|
|
hi,
If you are talking about windows application then you have to write custom functions like what you mentioned.
And you can provide ErrorProvider control for interactive error notification.
You can encapsulate your custom error checking here in Validated event of your textbox controls.
eg.
private void TextBox1_Validated(object sender, System.EventArgs e)
{
if(IsValid())
{
nameErrorProvider.SetError(this.TextBox1, "");
}
else
{
// Set the error if the name is not valid.
nameErrorProvider.SetError(this.TextBox1, "Name is required.");
}
}
**************************
S r e e j i t h N a i r
**************************
|
|
|
|
|
|
Hello,
Is there any way to prevent a tool like Reflector (http://www.aisto.com/roeder/dotnet/) from reading and disassembling private members using reflection?
I am aware of a suggestion posted by Microsoft, stating that using [StrongNameIdentityPermission...] may help, but I can't find any example for a successful usage of it. Using
[assembly: ReflectionPermission(SecurityAction.RequestRefuse, TypeInformation=true)] (or any other flag)
also proved futile.
Can it be that an assembly created using C# and .NET has no secrets when challenged by a freeware tool? And say I have secrets, does it mean I have to stick with C++ (knowing that you need a capable disassembler and a more capable person to squeeze the data out of my modules)?
Best
J
|
|
|
|
|
There are tools out there that can help you out a little. They are called obfuscators. What they do is they modify method names and class names to make it more difficult for someone to read your code. The more advanced tools insert special code to foil tools like Reflector.
Do a search for Salamander (expensive)
|
|
|
|
|
Thanks, I am familiar with these (actually wrote one myself for Java).
Unfortunately, even these tools with very advanced logic can only rename and scramble a little... this is certainly not the case with a C++ application, there you have to actually know ASM to understand the code, or use a disassembler that gets no-where close the original code.
I reviewed numerous obfuscators during the last weekend. Salamander is not expensive compared to others, but it has a very mediocre UI. I understand that its most valuable (advertised) feature is its ability to convert the code to what you would have gotten, had you used C++ (or other not managed language) to begin with...
It seems that Microsofties themselves are using Dotfuscator (which is bundled with DevStudio).
Still, I see no way to protect your *private* (not the public interfaces) code with managed code, and hence no reason to use it for project that you want to keep as inconspicuous as possible (like encryption libraries etc).
|
|
|
|
|
I was going to mention that even C++ can't hide your data, but you already know that. Well, I guess you can just create an unmanaged library for your most important functions and then use interop. If you need to release this as a component then create a wrapper library.
|
|
|
|
|
You set the plan as it will be 
Obfuscation for the code, unmanaged library for the encryption related code. This will (hopefully) shift the culprit's gain-loss balance towards the loss column.
Thanks for your suggesions.
|
|
|
|
|
hi,
Please check this site for obfuscation and reverse engi:.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dotfuscator/dotf49m6.asp
**************************
S r e e j i t h N a i r
**************************
|
|
|
|
|
I have a custom install action where I need to have the user browse for a folder. I'm using the 1.1. framework. I set the RootDirectory and the SelectedDirectory, but when I run the dialog it does not show a browse window. Every property I set shows up. It just does not let me select a directory. The browse window is gone!!!
Has anyone else experienced this?
This signature left intentionally blank
|
|
|
|
|
Check if the COM threading model for your application is single-threaded apartment.
[STAThread]
static void Main()
{
...
}
Don't know why, but if it's multithreaded apartment, you get the described behaviour.
www.troschuetz.de
|
|
|
|
|
so i guess there's two camps; the java people who required all exceptions to be caught, or result in a compile error, and the C# people who decided it won't be enforced, and let you ignore exceptions all you want. i personally was divided and thought with the proper documentation, catching exceptions when you wanted is rather convenient than to have to write try-catch blocks EVERYWHERE necessary. well, i've only been programming C# a few months now, and it seems these uncaught exceptions are creeping up everywhere. i have noticed two things that has been happening, one bad and the other REALLY bad, but not sure what causes one to happen instead of the other. in the bad case, an uncaught exception percolates all the way to the top and you see it while running the app. that info can be used to solve the problem relatively easily. however, in the really bad case, which i just had happend to me, was when an exception was thrown and was uncaught but silently went unnoticed! on my mainform control, i was calling a listview.item.remove and sending in accidentally a null value. this was not in a try catch block and the exception seems to just vanish since i never saw anything happen at runtime; a silent and sometimes very hard to find bug, wouldn't you say?
i am a little confused. don't ALL exceptions uncaught eventually travel all the way up the call stack and out to the user? i know many hard to find bugs will happen if someone just puts a try-catch block around somerthing and does nothing useful with the exception, then it will have that silently disappearing effect. but in my case, how come an uncaught exception isn't thrown out to the user with some message box, like they usually do? i tried catcuhign it and rethrowing it, and still nothing happened.
|
|
|
|
|
An exception will continue to travel up the call stack until it is caught.
However, there are so many people that just catch general exceptions like
catch(Exception ex) that it will catch everything. These are notoriously bad to trackdown - I heard a story of a guy who specialises in tracking down that sort of thing and makes a fortune out of it.
Something that might help though, is to deliberately send in a null value, set the breakpoint on the Remove method call then attempt to step-into it. Obviously you cannot step-into the framework code, so the code will stop again at the next line of your code, hopefully from this point you should be able to see what is going on.
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell
Not getting the response you want from a question asked in an online forum: How to Ask Questions the Smart Way!
|
|
|
|
|
Dude. what so hard about tracking down a general exception. All you have to do is set a breakpoint. When the exception is hit you then check the inner exception, actual type of the exception, and look into the details. Take a look at the call stack. No problem at all.
What's hard to debug is when there is unreliable code from a third party that you have to depend on. Sometimes the code fails and there is little or no way of telling if something went south.
|
|
|
|
|
AK wrote:
Dude. what so hard about tracking down a general exception.
If you don't know what is throwing it and what is catching without handling it, but the bug it generates doesn't appear until later it can be very difficult to even know where to set the breakpoint.
AK wrote:
Sometimes the code fails and there is little or no way of telling if something went south.
I've had that one before. It was an absolute nightmare because it just failed without returning an error code or throwing an exception. I had to write extra code after it to ensure that file had been written to disk. 
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell
Not getting the response you want from a question asked in an online forum: How to Ask Questions the Smart Way!
|
|
|
|
|
> what so hard about tracking down a general exception.
There are some general exceptions that can occur just about any time, for example. Think of an ExecutionEngineException, a StackOverflowException ThreadAbortException or OutOfMemoryException. It's almost impossible to handle some of these exceptions so that your application will run as expected afterwards (for some, even your finally-blocks will NOT be executed). But even if we're talking about not so "serious" exceptions: Often a single call to some method may result in one of five or more different exceptions. A general catch-block will handle all of these. But I think that often it's almost impossible to be sure such a catch-block can handle all of these exceptions properly. What you may get is unexpected behavior of your application. You may not even notice that something's wrong the time the error occurs, but maybe hundreds of lines of code later, and then these exceptions ARE hard to track down.
So I agree with Colin: using a general catch (Exception)-block may be a not so good idea. Instead, trying to catch specialized exceptions is the way to go. On the one hand, you can be sure what has to be done to get your application into a defined state. On the other hand, if any exception occurs you don't expect, you instantly will see that something's wrong (unhandled exception). Your way (setting a breakpoint) requires that you KNOW something went wrong. Handling general exception, this may not be the case, you may just get very unexpected behavior of your application afterwards, not knowing where the actual problem lies.
Just my 2 cents...
|
|
|
|
|
vista27 wrote:
well, i've only been programming C# a few months now, and it seems these uncaught exceptions are creeping up everywhere.
There's your problem right there
vista27 wrote:
don't ALL exceptions uncaught eventually travel all the way up the call stack and out to the user?
As far as I am concerned, that is the case, yes.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Are you sure that the exception that is being thrown is on the main application thread. I think that exception created on worker threads don't automaticly bubble up to the default exception handler. I remember reading somewhere how to redirect worker thread exception back to the main thread exception handler. You will have to check the documentation for this though.
Hope this helps.
BTW There is an artical somewhere on the web about why they did not require exception catching in C#. I think it was on the desware site.
Anyway....
Forever Developing
|
|
|
|
|
To answer your questions:
(1) No. NET does not mandate exception handling like Java. One reason I can think of is the performance, try-catch blocks involve extra code being inserted by the compiler around your own code and it has certain performance cost to pay.
(2) Your case about a thrown exception vanishing is very odd. Are you sure it is an exception and not just a logic error? Can you debug and find out where the exception is being ‘eaten out’? Somewhere down the stack an empty catch block like the following must be eating your exception.
catch<br />
{<br />
}
(3) I think there is a simple rule of thumb for exception handling:
a. Handle the logic errors with error codes and conditional statements.
b. For exceptional errors with high probability (Internet connection not available for example) have *specific* exception handling logic.
catch(System.Web.HttpException ehttp)<br />
{<br />
return false;<br />
}<br />
catch(System.Web.SomeotherException eother)<br />
{<br />
return false;<br />
}
c. For exceptional errors with remote probability (e.g. disk out of space) a *universal* exception handler in the main() function or major functions in the code will work well.
catch(Exception e)<br />
{<br />
return false;<br />
}<br />
catch<br />
{<br />
return false;<br />
}
This approach will ensure a balance between performance and stability. Any suggestion, friends?
|
|
|
|
|
Also it is a nice idea to print the StackTrace in a log file in case of major exceptions. (Point 3 c above) Thats helps shoot down production environment problems.
|
|
|
|
|
Requiring exceptions to be caught will eventually make people code with bad habits. Most of the time you dont want to catch the exception anyway, because you cant do anything about it at that level. I ask myself two questions about a block of code, when it comes to exceptions being thrown by it: 1. Can I recover from it? If yes, then catch and write recovery code. 2. Can I provide useful information about the context in which the exception was thrown? If yes then catch, and throw a new exception with the catched as inner exception.
Most code blocks will not fall under these categories, and should not have enforced catches. Forcing people to write catches will bloat the code so it's not readable (catches everywhere, the meaningful catches dont stand out). MS did a good design choice to leave out enforced catches.
BTW, to me exceptions are thrown mainly because of reasons out of your control: failures in the platform, execution engine, 3'd party library, etc. Or bugs in your code (arguments out of range, asserts gone bad, etc). They should never be used for general error handling.
Regards,
Björn Morén
Stockholm, Sweden
|
|
|
|
|
Actually I believe not enforcing exception handling is what make people code with bad habits. With
unchecked exceptions it's just too easy to ignore exception handling all together! You call a method on an object, you don't really know what exceptions it *might* throw, you don't have time to find out and you just forget exceptions even exists. The compiler won't complain, the code will run and everyone's happy.
MyObject myObject = new MyObject();
myObject.doSomething();
If I don't know what doSomething throws at me, in the best case scenario I could catch the generic Exception. But that still isn't good practice, right? Maybe I just leave it and let it propagate to my caller, who will be even more clueless about the exceptions that could generate inside doSomething.
But if you had doSomething throwing checked exceptions you wouldn't have a choice but to deal with them. And if you consider you can't do anything about it, Java will let you propagate it using the throws statement in your method declaration. The difference is it's all explicit and clearer. You know what's coming at you and you can decide to handle it or explicitly tell your caller to do it.
Cheers.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
