try
{
}
finally
{
}
> In certain code blocks I don't want to do anything when an error is
> raised. I simply want that application must remain stable instead of
[quoted text clipped - 9 lines]
>
> Since I am not using ex, it raises too many warnings.
David Anton - 24 Jan 2008 14:32 GMT
The application will still crash. You need an empty 'catch' block, not an
empty 'finally' block. There is absolutely no case where an empty 'finally'
block would be useful.

Signature
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++ VB Edition: VB to C++/CLI
Instant C++ C# Edition: C# to C++/CLI
> try
>
[quoted text clipped - 21 lines]
> >
> > Since I am not using ex, it raises too many warnings.
Peter Bromberg [C# MVP] - 24 Jan 2008 16:25 GMT
Good "catch". :-)

Signature
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com
> The application will still crash. You need an empty 'catch' block, not an
> empty 'finally' block. There is absolutely no case where an empty 'finally'
[quoted text clipped - 25 lines]
> > >
> > > Since I am not using ex, it raises too many warnings.
> In certain code blocks I don't want to do anything when an error is
> raised. I simply want that application must remain stable instead of
[quoted text clipped - 9 lines]
>
> Since I am not using ex, it raises too many warnings.
You can use :
try{
}
catch(Exception){
}
no warnings ;-)
KWienhold - 24 Jan 2008 14:17 GMT
> > In certain code blocks I don't want to do anything when an error is
> > raised. I simply want that application must remain stable instead of
[quoted text clipped - 19 lines]
>
> no warnings ;-)
If you don't care about the type of exception you catch you can even
write:
try
{
}
catch
{
}
It should be noted that if you catch an Exception (or just have a catch
statement) that your application won't necessarily be "stable". In catching
all exceptions (instead of just ones you know are going to be thrown) you
are corrupting your application state to some degree, and if you aren't
fastidious about defining the boundaries of your application, you will have
unexpected errors because of exceptions that were thrown and ignored in
other areas.
In other words, be very careful about proceeding in this manner. There
are reasons that exceptions are thrown, and you should ignore them at your
own peril.

Signature
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com
> In certain code blocks I don't want to do anything when an error is
> raised. I simply want that application must remain stable instead of
[quoted text clipped - 9 lines]
>
> Since I am not using ex, it raises too many warnings.
Lasse Vågsæther Karlsen - 25 Jan 2008 10:21 GMT
> It should be noted that if you catch an Exception (or just have a catch
> statement) that your application won't necessarily be "stable". In catching
[quoted text clipped - 7 lines]
> are reasons that exceptions are thrown, and you should ignore them at your
> own peril.
For some reason an image of an old map popped into my head containing
"Here there be dragons!" :)

Signature
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3