Exception handling

[Raj]

VB.NET does support both structured exception handling (try...catch) and
unstructured exception handling (on error goto...).

Does C# support the same?

Thank you

Regards
Raj

 

[Patrice]

Even in VB this is for legacy support. What are you trying to do ? (port
code ?). Even if porting to VB.NET it would be best to convert to
try/catch...

 

[Scott M.]

No. The only reason VB has two mechanisms is because the On Error... was
carried forward from the old VB 6.0. C# was built from scratch and does not
have such baggage.

Even though VB.NET supports the older style, you should avoid it and strive
to replace any such usage with the Try...Catch paradigm, as it is more in
line with general best practices.

-Scott

 

[Gregory A. Beamer]

VB.NET does support both structured exception handling (try...catch) and
unstructured exception handling (on error goto...).

Does C# support the same?

try ... catch? certainly

Ugly goto statements? No. They are left in VB (.NET) for people who did not
understand a single point of return. ;-)

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************

 

[Jeff Johnson]

for people who did not understand a single point of return. ;-)

Them's fightin' words!!

 

[Peter Duniho]

And 100% accurate...

I dunno. Ironically, one of the primary uses of "goto" in C# (other than
fall-through "case" statements) is to allow for a single point of return,
rather than having multiple "return" statements.

In other words, a person using "goto" in C# may well not only understand
"a single point of return", but may be using the statement as a way to
accomplish that.

Pete

 

[Jeff Johnson]

And 100% accurate...

Let the holy wars begin!

 

[Gregory A. Beamer]

Them's fightin' words!!

I assume you mean VB.

I was a VB developer for years, so I understand what the GOTO solved.
But, in most cases, people got used to the hammer and searched for
nails. With VB.NET, they carried the "training wheels" in the form of
microsoft.visualbasic.compatibility.

If you want some history, there were some prominent VB developer (MVPs)
who argued for things like treating integers as Booleans for comparison
(ie, anything not 0 is true). Many of the contructs made it into .NET,
while others died out. Nobody was left happy with the compromise.

We have the ability to ref and out parameters in C#, which can lead to
multiple returns if used incorrectly, so C# is not exempt from the fray.
I may take that back about out, as it is a bit trickier. nah, I will
keep that one in after mulling it over a bit.

Bad design is bad design, in any language. Some languages just give you
more tools to whack you thumb with.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************

 

[Gregory A. Beamer]

I dunno. Ironically, one of the primary uses of "goto" in C# (other
than fall-through "case" statements) is to allow for a single point
of return, rather than having multiple "return" statements.

In other words, a person using "goto" in C# may well not only
understand "a single point of return", but may be using the statement
as a way to accomplish that.

I accept that there are some instances where this works. Like any
"rule", there are good reasons around it. And, I can see the goto being
used to send everything to a single out.

More likely, however, the routine is trying to accomplish too much and
refactoring the code that "requires" the goto(s) to its own routine(s)
will better solve the problem. I wish i could think of an example to
code off the top of my head. ;-)

Often times we use things like goto to reduce the number of lines we are
coding, but number of lines is not the primary problem in most
instances, except perhaps when performance beats out all of the other
metrics of development. In general, however, if you are coding to save
lines, you are also introducing the likelihood of logical errors, which
are much harder to debug.

There is very little you can say in computers that is 100% true all the
time (except perhaps "everything in the computer eventually breaks down
to a Boolean or a set of Booleans" - think about it before refuting),
but I have yet to see the use of a goto that cannot be better solved by
re-architecting to multiple routines. Once again, this is 99% statement,
as I allow there is possibly an example where this is not true (just
like you denormalize databases sometimes for good reason, while
normalization is the "rule").

I guess I can sum up this post like this. If I were to err on goto, I
would err on the side that the routine could be improved and only leave
the goto if I could not think of a better way of coding it. Someone else
might make a different decision, which I accept.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************

 

[Jeff Johnson]

I assume you mean VB.

Nope. I meant the concept of "single point of return." I do not subscribe to
it.

 

[Peter Duniho]

[...]

In other words, a person using "goto" in C# may well not only
understand "a single point of return", but may be using the statement
as a way to accomplish that.

I accept that there are some instances where this works. Like any
"rule", there are good reasons around it. And, I can see the goto being
used to send everything to a single out.

More likely, however, the routine is trying to accomplish too much and
refactoring the code that "requires" the goto(s) to its own routine(s)
will better solve the problem. I wish i could think of an example to
code off the top of my head. ;-) [...]

I don't disagree that there are lots of ways to misuse "goto". It's the
"who did not understand a single point of return" that I take issue with.
Not only is "a single point of return" not really a universally accepted
design requirement for code (e.g. lots of valid code can be found with
multiple return statements), a person who does subscribe to the "single
point of return" philosophy may correctly use "goto" to accomplish that.

Pete

 

[Gregory A. Beamer]

Nope. I meant the concept of "single point of return." I do not
subscribe to it.

Why not? You like code that is harder to maintain? ;-)

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************

 

[Harlan Messinger]

Nope. I meant the concept of "single point of return." I do not subscribe to
it.

I am SO glad to see this opinion being expressed. One of my professors
drilled into us the need to have a single point of return, combined with
always handling the nominal case *first*, and he was unyielding on it. I
always thought it had the opposite effect of the one he claimed: it
forced me to save return results in temporary variables and to wade
through scores of lines of code that no longer had anything to do with
the scenario I was debugging or testing, carefully, so that I didn't
risk losing my place or missing something important. I gave up this
practice long ago but still occasionally think about it. This is the
first mention of it I've seen since I had that professor, and it
validates my feeling that exceptional case first, return as soon as
possible is the better principle.

 

[Peter Duniho]

Why not? You like code that is harder to maintain? ;-)

Frankly, with or without the emoticon, that's a narrow-minded, prejudiced
reply.

There are at least three _valid_ constructions for a method:

-- Completely structured, no gotos and a single point of return
-- Completely structured, no gotos, multiple points of return
-- Single point of return, with gotos to control flow to that point of
return

Each has its own advantage, and what suits a particular method best
depends on the complexity of the method. Having a single point of return
in a completely structured method can require additional indentation that
someone would like to avoid. Often, the most natural way around that is
to provide for multiple points of return in the method. Sometimes, one
should instead refactor the method into multiple methods, but that can be
more work and sometimes requires excessive parameter passing or the
creation of a whole new helper class, to keep all the relevant data
available to the methods useing it.

Of course, sometimes refactoring is exactly what's needed. But not
always. In any case, arguing that _only_ the first construction above is
valid is as confrontational and inflammatory as Jeff's reply suggests.

Pete

 

[Jeff Johnson]

Why not? You like code that is harder to maintain? ;-)

Heh. And I should have said "I do not subscribe to it DOGMATICALLY." Most of
my procedures do have a single point of return, but if I feel things are
better handled with multiple returns, I use them and don't agonize over it.

While there are both pros and cons about being self-taught, one of the
definite pros is the absence of brainwashing from some CS professor and the
subsequent guilt felt when you deviate from his "unyielding" (as Harlan put
it) point of view.

 

[Gregory A. Beamer]

[...]

In other words, a person using "goto" in C# may well not only
understand "a single point of return", but may be using the
statement as a way to accomplish that.

I accept that there are some instances where this works. Like any
"rule", there are good reasons around it. And, I can see the goto
being used to send everything to a single out.

More likely, however, the routine is trying to accomplish too much
and refactoring the code that "requires" the goto(s) to its own
routine(s) will better solve the problem. I wish i could think of an
example to code off the top of my head. ;-) [...]

I don't disagree that there are lots of ways to misuse "goto". It's
the "who did not understand a single point of return" that I take
issue with. Not only is "a single point of return" not really a
universally accepted design requirement for code (e.g. lots of valid
code can be found with multiple return statements), a person who does
subscribe to the "single point of return" philosophy may correctly
use "goto" to accomplish that.

I can actually see this in my code, as exceptions thrown can be a
separate form of return, as can this:

switch(foo)
{
case "bar": { return 0; }
default: { return 1; }
}

But this is not as huge an exception as some, as the entire routine is
focused on answering the question. It could be refactored to use an
enumeration and greatly simplified, of course, but the multiple returns
work as the purpose of the routine is to branch and give an answer, so
it is not a single point of return, but functionally it serves the
purpose if each branch is considered a point of return. Swatting gnats
here.

Now, if one was a single return purist, they would go to:

int retVal = 1;

switch(foo)
{
case "bar"
retVal = 0;
default:
retVal = 1;
}

return retVal;

Or similar. Regardless of the lack of single return spot in the code, I
would say that following the rule of "single point of return" and then
breaking when appropriate is more sound than return whenever you desire.
This is more from a maintenance standpoint than anything else.

Peace and Grace,


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************

 

[Gregory A. Beamer]

Frankly, with or without the emoticon, that's a narrow-minded,
prejudiced reply.

This makes an assumption on intent that was not present.

There are at least three _valid_ constructions for a method:

-- Completely structured, no gotos and a single point of return
-- Completely structured, no gotos, multiple points of return
-- Single point of return, with gotos to control flow to that
point of
return

Each has its own advantage, and what suits a particular method best
depends on the complexity of the method. Having a single point of
return in a completely structured method can require additional
indentation that someone would like to avoid. Often, the most
natural way around that is to provide for multiple points of return
in the method. Sometimes, one should instead refactor the method
into multiple methods, but that can be more work and sometimes
requires excessive parameter passing or the creation of a whole new
helper class, to keep all the relevant data available to the methods
useing it.

And, with your experience, I would assume you will think through the
options and make the proper choice. The problem is many do not have your
experience and do not make proper choices. Setting up a rule, or
guideline, and then attempting to follow it as religiously as possible,
is better for the run of the mill developer.

My personal experience is when you adopt a loose style, the junior devs
end up with the following scenario:

You start with multiple points of return as a rule (as the junior dev is
not experienced enough to see three potential coding styles). After all,
just writing this

return x;

is easier than thinking through the problem. Since he also does not
understand refactoring, he does not realize that some of the code needs
to be moved to other routines, so the routine grows ... very large.
Since he can return anywhere in the routine, the routine ends up solving
numerous problems, but has a single return type.

Of course, sometimes refactoring is exactly what's needed. But not
always. In any case, arguing that _only_ the first construction above
is valid is as confrontational and inflammatory as Jeff's reply
suggests.

I never argued that it was the "only construct". My statement was, as a
rule, aim for single return first and break when necessary.

As for confrontational and inflammatory, the statement that got your
craw was designed as a funny off-handed comment. I apologize that i
could not convey the light heartedness I felt as I wrote the comment.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************

 

[Gregory A. Beamer]

Heh. And I should have said "I do not subscribe to it DOGMATICALLY."
Most of my procedures do have a single point of return, but if I feel
things are better handled with multiple returns, I use them and don't
agonize over it.

There are, but even the multiple returns should be handled
systematically.

For things that you do for yourself and do not share, you can adopt any
style you want. The issue comes when you have to maintain or work with
people you are mentoring. If you adopt a loose standard, or no standard,
you oft end up teaching bad habits to others. This is why we start with
rules and then break them when needed.

While there are both pros and cons about being self-taught, one of the
definite pros is the absence of brainwashing from some CS professor
and the subsequent guilt felt when you deviate from his "unyielding"
(as Harlan put it) point of view.

Professors, when used correctly, get you the discipline you normally
lack when you are self taught, but i agree they can lock you into "rules
are rules and are never broken".

For the record, I am self taught. But I found that I became a much more
valuable developer when I started teaching myself the basics I missed
from not having a CS degree.

And, btw, I hope you realize many of the comments I have made are in
jest. I use multiple points of return when they are the best way to
serve the problem. I do not code that way very often, as refactoring
often leads to a better solution, but one clear exception is a lookup
routine, where it is more efficient to code multiple returns in switch
than it is to set a return value and then return it.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************

 

[Gregory A. Beamer]

I am SO glad to see this opinion being expressed. One of my professors
drilled into us the need to have a single point of return, combined
with always handling the nominal case *first*, and he was unyielding
on it. I always thought it had the opposite effect of the one he
claimed: it forced me to save return results in temporary variables
and to wade through scores of lines of code that no longer had
anything to do with the scenario I was debugging or testing,
carefully, so that I didn't risk losing my place or missing something
important. I gave up this practice long ago but still occasionally
think about it. This is the first mention of it I've seen since I had
that professor, and it validates my feeling that exceptional case
first, return as soon as possible is the better principle.

Much of what you have here can be both correct or incorrect depending on
platform and/or language.

Exceptional versus nominal first:

If you are dealing with input validation (what code contracts is
supposed to aid with in .NET 4.0), you would code exception first, as
you might as well throw out items that will not make it through the
routine. This is more efficient, especially in "traffic cop" type of
routines (of course, inversion of control can eliminate some of this
argument). There are probably other reasons to have exception first, but
this is a primary case. Once again, the code contracts may eliminate the
need to explicitly code some of this.

Outside of these types of cases, i would aim for nominal first, but I
also subscribe to a TDD approach to development, so solving the problem
with as few lines of code as possible is the first step.

Single Point of Return:

The reason for the "rule" is discipline. If you try to adhere to the
rule first, you find that you generally end up with better code. The
reason is you do not end up taking sloppy short cuts (aka, kludges) to
get through the routine.

As with all "rules", there are instances where you have to break it.
But, if you adhere first to the rule and then break when needed, you
find you have better code.

Professors are there to drill in the basics. over your college career,
you generally find the classes more rigid at first and less as you get
to upper level courses. If you had an upper level professor that
subscribed to ALWAYS, you probably were dealing with an ideologue.

Regardless, if they don't initially teach things as rules, you do not
take the ideas seriously.

Peace and Grace,


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************

 

[vanderghast]

You already have your answer for the TRY/CATCH, unfortunately, there is no
equivalent in C# to "on error resume next" or other statements which
preserve the (entire) context of the error. Try/Catch does not preserve the
try{} scope, from all evidence, when you are in the catch!

VB.Net is the only language I know, in the Dot-Net family, which CAN
preserve the context of the error, when it occured, although it is rumored
that other languages also support it: Smalltalk, Common Lisp, APL, ... No,
it is not just a matter to have a "go to", and it is not either "anti-oop"
to have something ELSE than the try-catch error trapping, and unless you
try-catch each statement (which is not sugested), you may end up with the
following algorithm:

Program: Going to see a film with the girlfriend when you are 16.
- Phone the girlfriend
- Ask the permission to get mom's car
- Get the car
- Drive to girlfriend home, and pick the girlfriend
- Drive to the theater.. oops.. error... out of gaz... catch
the problem, fill up the tank... or get a flat, whatever... and once the
problem is solved....
- Phone the girlfriend
- Ask the permission to get mom's car
- Get the car
- Drive to girlfriend home, and pick the girlfriend
...

Sure, sure, you can do it 'intelligently' too with try/catch, but more work
is involved than with an exception handling keeping the context, with goto
or not, 'goto" which do not destroy object philosophy, per se.



Vanderghast, Access MVP