|
If your setting is a User Setting, you need to save all the current User Settings to make them persist between Application use; if your Setting is an Application Level Setting, you cannot change it at run-time. In the Visual Studio Settings Designer you can change the scope of a Setting to 'User.
Properties.Settings.Default.Save(); Quote: Settings that are application-scoped are read-only, and can only be changed at design time or by altering the .config file in between application sessions. Settings that are user-scoped, however, can be written at run time just as you would change any property value. The new value persists for the duration of the application session. You can persist the changes to the settings between application sessions by calling the Save method. [^]
I found the information here useful: [^].
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
|
|
|
|
|
Ahhhh...yes, the difference (for me) was that I had some items set to Application and thus they were read-only. I changed them to User and can now save their data.
Thanks Bill.
|
|
|
|
|
Bill, this is the oddest site to find things, you mention before to delete a message and repost it but there was no way to delete. Now you're suggesting I vote a thank you which I 100% agree with but I don't see anything regarding voting. Strangest site!
|
|
|
|
|
There are little red (down vote) and green (up vote) arrows to the left of the message you want to vote on. Just open the message and move your mouse towards the left side under the document icon and it'll show the voting arrows.
At the bottom of your messages are the links to edit/delete, etc. You can use those too.
|
|
|
|
|
Yep, I went to look again and finally figured that out!!! Up vote to you Bill...!!
|
|
|
|
|
rfresh wrote: Up vote to you Bill..
But you still have not upvoted his message.
Use the best guess
|
|
|
|
|
I dont have a habit of using try-cahtch block unless i am sure it throws an exception... is it advisable to use it in most places of your code.... what is the best practice?
Srinivas K
|
|
|
|
|
Srinivas Kalabarigi wrote: what is the best practice?
To only catch what you can handle. If you can't handle it, don't catch it. If it doesn't throw exceptions, don't try.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
You mean to say its not good practice to catch all....?
Unless necessary... right
Srinivas K
|
|
|
|
|
Srinivas Kalabarigi wrote: You mean to say its not good practice to catch all....?
It's a known anti-pattern; catching all is the worst practice, a remnant of the "On Error Resume Next" lazyness.
Catching an unexpected exception might lead to unexpected behaviour (since your app is in an unknown state), data-loss, and generally makes it harder to solve bugs.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Catching an unexpected exception might lead to unexpected behaviour... (
Except of course that in servers
1. Not catching it means it is lost.
2. Most of the time, most errors are non-disruptive. For example null pointer errors, and in a correctly designed layered system such errors, although unexpected, will not stop the application.
|
|
|
|
|
It is a good practice to catch exceptions; but if someone is sure about some exception then it is better to work on your code so that it doesn't throw any exception; let's say if divide by zero throws an exception then you shouldn't allow your code to reach to that point so that division by zero may occur. In that case it is not recommended to use the try-catch block but it is recommended to not let your code reach to that point so that that exception may occur.
|
|
|
|
|
I dont pay much attention to practices when it comes to exceptions.. I guess it depends on what you are coding...
However, I have coded both pro app and pro web sites..
And I must say....
The best use of catch exception code for me has always been...
If Website, catch just about all exceptions and store them into a database for review and easy lookup for when users report bugs and problems that may be very hard to reproduce on your own..
In applications, catch exception and present user with interface to report exception to staff..
That has been the extend of my exception code...
=)
|
|
|
|
|
Forbiddenx wrote: catch just about all exceptions
Not using a try-catch construction; there's an event that's raised for unhandled exceptions; that's the place where one would log them.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yes, I know what your talking about..
But I typical do this.. where i want to log data because it gives me more control.
And sometimes depending on what the exception is and where it happened, i don't log it...
So, if i did it in the exception event.. it would have less control.
But I do see what your saying.. and its also a method that works.
Try
{
some code
}
catch (Exception exc)
{
log it, or present it to the user exc...
}
=)
|
|
|
|
|
Forbiddenx wrote: where i want to log data because it gives me more control.
And sometimes depending on what the exception is and where it happened, i don't log it...
How do you have "more" control?
I do hope that you catch specific exceptions, and aren't advocating a pokemon-handler? Swallowing exceptions is a worst-practice:
catch (Exception exc)
{
log it, or present it to the user exc...
}
And how is it preferable to have your code littered with repeating code, consisting of merely a try-and-log? Simply log from the one place where all unhandled exceptions end up, and be done with it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I think we are misunderstanding each other.
I do use specific exceptions but at times I also use the generic all exceptions..
But, I also bomb out if I use the generic all exception and stop everything in its tracks.
catch (Exception exc)
{
log it, or present it to the user exc...
BOMB OUT.... alert.. done.
I never resume operation that would be bad!
}
I only resume operation if I
catch (ExceptionTYPE exc)
{
try to recover..
}
Yes, it does add some extra code, but it is better then resuming you want to log any exception that occurs globally.
=)
|
|
|
|
|
Forbiddenx wrote: But, I also bomb out if I use the generic all exception and stop everything in its tracks.
There's the problem; handling a "specific" exception means that you cannot use the generic exception to handle it - it'd be passing in other exceptions that weren't meant to be handled that way. Nice example is a Sql Server that's offline, and a client-app that keeps whining about a password being incorrect (since that was all that's handled locally).
Hence, the best practice would be to catch and handle what you expect, and to log everything else on a higher level.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: that's the place where one would log them.
But only at the top-most layer.
|
|
|
|
|
Forbiddenx wrote: If Website, catch just about all exceptions and store them into a database fo
And what happens when the database throws an exception?
|
|
|
|
|
That hardly ever happens. 
|
|
|
|
|
I am going to compound a little on Eddy's
Don't catch what you can't handle
Don't throw what you can catch
Expected exceptions are not exceptions test first, your code will be more rigorous.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Don't throw what you can catch
Unless you are a value-added re-thrower.
|
|
|
|
|
I catch everything on layer boundaries. What happens there depends on the layer and where I catch it.
I catch everything on adapter boundaries, although that is just a specialization of a layer boundary. However I also tend to catch everything at the adapter top level as well.
When I catch everything then handling involves the following
1. log it, and take appropriate action which might include throwing a different exception WITHOUT including the original exception.
2. Don't log it and take appropriate action which might include throwing a different exception INCLUDING the original exception in the new exception.
I do NOT use catch alls which do nothing but log and then rethrow. That is pointless and a waste of time since the caller should be catching and will then end up logging as well.
There are of course extreme conditions where the above can be problematic. For example out of memory errors. Those can cause the log to fail as well. However without some logging figuring out an out of memory occurred is impossible. There are things like stack over flow in C# which CANNOT be caught so one is kind of out luck there.
This however does NOT mean that one can ignore the code that one is working with. If I am working on a communications layer then I expect communication exceptions. And I expect to take specific actions with regards to those.
I suppose what it really comes down to is that I use catch all because I am almost certain that some unexpected exception will occur at some point and I need to still behave in some reasonable manner. At other times I am not certain and thus it is inappropriate to take such action. Which is why boundary layers are often the only place this occurs.
|
|
|
|
|
Srinivas Kalabarigi wrote: i am sure it throws an exception
That's silly; how do you do that?
Srinivas Kalabarigi wrote: use it in most places of your code
No, only where it makes sense.
Srinivas Kalabarigi wrote: what is the best practice
That depends on your situation; different domains require different techniques.
I work mostly in the back-end with libraries and databases, which is very different from the front-end.
Most times I have a catch, it's a catch-all; I rarely need to have special handling for different Exceptions.
The main thing I usually need to do is to add information to the Data collection of the Exception and rethrow it.
Many times, I also need to rollback a transaction or perform some other clean up task.
Also, most times that a problem happens in a database all I get is a System.Data.DataException and I have to investigate it to see what the problem was -- deadlock, timeout, duplicate key, etc. (and no two database systems report it the same way) -- then I can wrap the DataException in a more detailed custom Exception -- DeadlockException, TimeoutException, DuplicateException, etc. and throw it so the caller can decide how to procede.
The main thing here is to add information to make the caller's job easier; but the ultimate decision of what to do is up to the caller.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
