on error resume next in c#

[Guest]

Hi,

We have on error resume next option in vb language but we dont have that in
c#. I just want to do the same kind of functionality in c#.

Any help is really appreciated.

 

[Peter van der Goes]

Hi,

We have on error resume next option in vb language but we dont have that
in
c#. I just want to do the same kind of functionality in c#.

Any help is really appreciated.

There is no direct equivalent in C#. Exception handling in C# (and VB .NET
if done properly, IMHO) is through try...catch...finally.
By placing appropriate code in your catch block you can probably approximate
what you want as once an exception is "caught", execution will resume at the
statement(s) following the try...catch...finally block.

 

[Guest]

There are actually at least a half dozen things you can do in VB.NET that you
can do in C# and vice-versa (this example, DirectCast, "when" clauses, types
within interfaces, non-constant switch/select case expressions are five just
off the top of my head). As the other poster stated, there is no equivalent
to On Error Resume Next. To simulate it, you'll have to enclose every
statement you want affected with a separate try/catch block where the catch
block is empty.
e.g.,
try
{
<statement 1>
}
catch
{
//do nothing
}
and so on for *every* statement.

As you can see, the C# equivalent (or rather, pure .NET equivalent) really
is not very viable unless you only have a few statements to apply this
approach to.
--
David Anton
www.tangiblesoftwaresolutions.com
Home of:
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter

 

[Lloyd Dupont]

oh.. a entusiastic VB professional who seems to know a bit of C# as well...

out of curiosity could you describe for me, a bit more in detail, what are
these construct you speak of (DirectCast, When) (the other are quite self
explanatory)?


out of curiosity...

 

[Guest]

Actually, I work in all the main .NET languages (except not much in C++ yet).
I don't promote one over the other - we produce converters to switch between
them (to C# from VB, to VB from C#, to J# from VB) so it would not helpful if
I did promote one over the other.

C# also has about as many unique features that VB doesn't have.

DirectCast is a way of casting which essentially bypasses preliminary type
checking - it's a way of saying "I'm so sure that the run-time type is what
I'm casting to that there is no need to check - just go ahead and throw that
exception if I'm wrong". The upshot is that it's faster than VB's other
casting operator "CType", but also more dangerous - and no, there is no
special extra fast cast operator in C#.

"When" is a way to additionally filter the exception being caught - there is
no equivalent in C# - filtering within the catch block does not produce the
same effect since it would occur after the catch block is chosen and entered.

--
David Anton
www.tangiblesoftwaresolutions.com
Home of:
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter

 

[Lloyd Dupont]

I see....
thanks for that!

for me I used mainly C# and (recently) Managed C++, well I could understand
why you don't work with Managed C++.
Syntaxically speaking it's like C++, with additional extra stuff (and v1 was
ambiguous as well... but I work with v2 beta2!)

Actually, I work in all the main .NET languages (except not much in C++
yet).
I don't promote one over the other - we produce converters to switch
between
them (to C# from VB, to VB from C#, to J# from VB) so it would not helpful
if
I did promote one over the other.

C# also has about as many unique features that VB doesn't have.

DirectCast is a way of casting which essentially bypasses preliminary type
checking - it's a way of saying "I'm so sure that the run-time type is
what
I'm casting to that there is no need to check - just go ahead and throw
that
exception if I'm wrong". The upshot is that it's faster than VB's other
casting operator "CType", but also more dangerous - and no, there is no
special extra fast cast operator in C#.

"When" is a way to additionally filter the exception being caught - there
is
no equivalent in C# - filtering within the catch block does not produce
the
same effect since it would occur after the catch block is chosen and
entered.

--
David Anton
www.tangiblesoftwaresolutions.com
Home of:
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter

 

[Daniel O'Connell [C# MVP]]

Actually, I work in all the main .NET languages (except not much in C++
yet).
I don't promote one over the other - we produce converters to switch
between
them (to C# from VB, to VB from C#, to J# from VB) so it would not helpful
if
I did promote one over the other.

C# also has about as many unique features that VB doesn't have.

DirectCast is a way of casting which essentially bypasses preliminary type
checking - it's a way of saying "I'm so sure that the run-time type is
what
I'm casting to that there is no need to check - just go ahead and throw
that
exception if I'm wrong". The upshot is that it's faster than VB's other
casting operator "CType", but also more dangerous - and no, there is no
special extra fast cast operator in C#.

I'm sorry, but you are pretty much wrong here. Standard C# casting and
DirectCast are identical in the circumstances DirectCast is used, its the
CType syntax that C# doesn't support directly.

Compile these snippits andd examine the output code:

VB:
Dim X As Object = "TestString"
Dim Y As String = DirectCast(X, String)

C#:

object x = "TestString";
string y = (string)x;

and disassemble them. You will get nearly identical code. The only
difference I'm seeing currently is that the VB compiler issues a pop and the
C# compiler issues a stloc for the final assignment.

The difference is that the C# cast operator is overloaded to support
conversion operators, both user defined and compiler specific. That is a
issue with semanic explicity, but DirectCast offers no performance
advantage over normal C# casting when doing referential casting. so while
you are right that there is no special "extra fast" operator, you are wrong
in that there is no operator. The normal one already does it.

 

[Guest]

You are right - thanks for clarifying that.

David Anton
Tangible Software Solutions Inc.

 

[Yanir Kleiman]

I didn't understand why "When" is different then the following
exception catching construct:

try
{
....
}
catch (MyException ex)
{
// handle MyException type
}
catch (ArgumentException ex)
{
// handle ArgumentException type
}
catch (Exception ex)
{
// handle general Exception type (catches every exception that was
not previously handled)
}

Can you explain what you meant?

Thanks, Yanir

 

[Frans Bouma [C# MVP]]

There are actually at least a half dozen things you can do in VB.NET
that you can do in C# and vice-versa (this example, DirectCast,
"when" clauses, types within interfaces, non-constant switch/select
case expressions are five just off the top of my head). As the other
poster stated, there is no equivalent to On Error Resume Next. To
simulate it, you'll have to enclose every statement you want affected
with a separate try/catch block where the catch block is empty.
e.g.,
try
{
<statement 1>
}
catch
{
//do nothing
}
and so on for every statement.

As you can see, the C# equivalent (or rather, pure .NET equivalent)
really is not very viable unless you only have a few statements to
apply this approach to.

Though, On error resume next is really a statement to swallow any
exceptions because they're not interesting (according to the
developer). In any case, 'on error resume next' is a construct which
should be avoided as it leads to swallowed exceptions even ones you
might have liked to see being bubbled upwards.

If a person is so eager to use an on error resume next equivalent,
write a method which performs the action and catch the exceptions
there. In fact, that's preferable, as you can then still have certain
exceptions being bubbled upwards and others being swallowed.

Example is a Deserialization constructor. With increasing versions it
might be that some things have changed, which makes info.GetValue() to
fail and throw an exception. You can use On error resume next for that,
but then you also ignore other exceptions, or you an write a utility
method which handles the grabbing of the value for you, swallow the
exception which is related to the missing value in the info block and
simply bubble up exceptions which are related to other issues.

Without having a statement like on error resume next, you have to
choose the better route of the utility method. With a statement like on
error resume next, a lazy programmer can opt for that route, doing the
project more damage than initially anticipated.

Frans

--

 

[Jay B. Harlow [MVP - Outlook]]

Yanir,
"When" if far more flexibly then a simply Catch block.

Consider the following:

Try
Return GetField(name)
Catch ex As COMException When ex.ErrorCode =
MAPI.CdoErrorType.CdoE_NOT_FOUND
Return AddField(name, type)
End Try

The Catch block itself will only be entered for COMExceptions with an
ErrorCode of CdoE_NOT_FOUND. Which in this case indicates that the Field was
not found, for other exceptions I want the exception to continue to
tranverse the call stack upward...

In C# you would need to have the catch block for the COMException and then
have an if statement inside the catch block for the CdoE_NOT_FOUND, the if
statement would need an else throw to have the exception continue upward...

Another example I've used recently includes:

Try
m_response = DirectCast(m_request.GetResponse(),
HttpWebResponse)
Catch ex As WebException When TypeOf ex.Response Is HttpWebResponse
m_response = DirectCast(ex.Response, HttpWebResponse)
End Try

The Catch block is only entered for WebExceptions that have a Response of
type HttpWebResponse.

IMHO the major advantage of the "When" clause is I don't need a conditional
within the Catch block that rethrows the caught exception on the Else clause
of the conditional...

Hope this helps
Jay

|I didn't understand why "When" is different then the following
| exception catching construct:
|
| try
| {
| ...
| }
| catch (MyException ex)
| {
| // handle MyException type
| }
| catch (ArgumentException ex)
| {
| // handle ArgumentException type
| }
| catch (Exception ex)
| {
| // handle general Exception type (catches every exception that was
| not previously handled)
| }
|
| Can you explain what you meant?
|
| Thanks, Yanir
|

 

[Lloyd Dupont]

I will take this opportunity to say that I kind of think (guess would be
more exact) that the "CType" VB operator, if it does what I think it does,
is likely to work like the C# "as" operator.

just so you know ;-)

Actually, I work in all the main .NET languages (except not much in C++
yet).
I don't promote one over the other - we produce converters to switch
between
them (to C# from VB, to VB from C#, to J# from VB) so it would not helpful
if
I did promote one over the other.

C# also has about as many unique features that VB doesn't have.

DirectCast is a way of casting which essentially bypasses preliminary type
checking - it's a way of saying "I'm so sure that the run-time type is
what
I'm casting to that there is no need to check - just go ahead and throw
that
exception if I'm wrong". The upshot is that it's faster than VB's other
casting operator "CType", but also more dangerous - and no, there is no
special extra fast cast operator in C#.

"When" is a way to additionally filter the exception being caught - there
is
no equivalent in C# - filtering within the catch block does not produce
the
same effect since it would occur after the catch block is chosen and
entered.

--
David Anton
www.tangiblesoftwaresolutions.com
Home of:
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter

 

[Guest]

Actually, the "as" operator in C# has a direct equivalent only in VB 2005 via
the "TryCast" operator. The basic idea is that if the cast doesn't work the
expression evaluates to null. CType does not work that way - if the cast is
unsuccessful at run-time you'll get an exception.

--
David Anton
www.tangiblesoftwaresolutions.com
Home of:
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter

 

[Yanir Kleiman]

Yeah, thanks.
I will continue using C#, but it's nice to know the differences between
those two languages.

Yanir