Exception handling suggestions

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

In my opinion; C# error handling sucks.

managed error handling sucks.

on error goto errhandler was and is, far superior-- in every fashion

I heard that we're removing TRY CATCH in the next version of Visual
Studio, it should be out next month

Then you are badly misinformed.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

then learn how to program bugfree?

If you truely believe that it is possible to learn how to write bugfree
code, then you have long way to go until you get to be a good programmer.

uh.. instead of writing pointers, write a friggin UI?

VB has had a superior interface for 15 years.. your C# crap was never
invented

-Todos

 

[Bruce Wood]

If you truely believe that it is possible to learn how to write bugfree
code, then you have long way to go until you get to be a good programmer.

He's not a programmer. He's an attention-starved teenager trying to
get a response--any response--to his trolling. Best to ignore him. Or
feel sorry for him. I think he needs a girlfriend.

 

[Todos Menos [MSFT]]

bull mother ****ing shit dude

it's possible to write bugfree code.
Microsoft has brainwashed you into accepting mediocrity


SERIOUSLY HERE KIDS

bugfree code is possible when you've got $60bn in cash

they just don't produce it

 

[Todos Menos [MSFT]]

I'm not misinformed.

I'm not the one that's using the trendy 'programming language of the
month'

just because C and Java had a MOTHER ****ING _CRAP_ GUI for the past
10 years.. does that mean you should hop on the first language that's
competitive with VB?

VB won the war kid

Java -- I mean get real, Sun is worth what.. $3bn? PHP has 4 times the
following of Java..

In my opinion; C# error handling sucks.

managed error handling sucks.

on error goto errhandler was and is, far superior-- in every fashion

I heard that we're removing TRY CATCH in the next version of Visual
Studio, it should be out next month

Then you are badly misinformed.

-Todos

In my opinion, VB6 error handling was far inferior.
Shorter code is not always better code. What's difficult about
programming is not typing in the commands, so how much you have to type
has little impact on the efficiency of a programmer.
Besides, is it really more verbous?
This would roughly resemble the error handling in your VB6 example:
try {
} catch (IOException) {
} catch (FormatException) {
} catch (Exception ex) {
MessageBox.Show(ex.Message);
}
This is 108 characters compared to 158 (not counting tabs and line
breaks). Unless I have forgotten most of my math, that is much less, not
much more.
Handling different error types is built into the exception model, while
in VB6 you have to use a Select Case to determine the error type. Also
"IOException" says a lot more than "12345".
Exception handling fits well into the structure of the code, while in
VB6 error handling you have to jump back and forth in the code.
Spaghetti code is always harder to follow.
Todos Menos [MSFT] wrote:
in my opinion, vb6 error handler was much superior than this managed
crap.. i mean seriously-- it's a lot less verbose
Public Sub MySub
on error goto errhandler
CleanExit:
exit sub
ErrHandler:
Select Case Err.number
Case 12345, 1224334
resume cleanexit
case else
msgbox error$
resume cleanexit
end Select
End Sub
Ok something simple like int.Parse(string) can throw these exceptions:
ArgumentNullException, FormatException, OverflowException
I don't want my program to just crash on an exception, so I must
handle all of them. I don't care about which one happened, except to
write out exception.Message to a log file. It seems verbose to write
out three handlers that all do the same thing. So, I could just catch
Exception. But, is that recommended? It'll catch everything, even
out of memory exceptions.
What do you suggest?
Zytan

--
Göran Andersson
_____http://www.guffa.com- Hide quoted text -

- Show quoted text -

 

[Todos Menos [MSFT]]

I'm not mis-informed
i just don't accept VERBOSITY laying down

your try catch crap.. I mean seriously here.. what a waste of keyboard
effort

In my opinion; C# error handling sucks.

managed error handling sucks.

on error goto errhandler was and is, far superior-- in every fashion

I heard that we're removing TRY CATCH in the next version of Visual
Studio, it should be out next month

Then you are badly misinformed.

-Todos

In my opinion, VB6 error handling was far inferior.
Shorter code is not always better code. What's difficult about
programming is not typing in the commands, so how much you have to type
has little impact on the efficiency of a programmer.
Besides, is it really more verbous?
This would roughly resemble the error handling in your VB6 example:
try {
} catch (IOException) {
} catch (FormatException) {
} catch (Exception ex) {
MessageBox.Show(ex.Message);
}
This is 108 characters compared to 158 (not counting tabs and line
breaks). Unless I have forgotten most of my math, that is much less, not
much more.
Handling different error types is built into the exception model, while
in VB6 you have to use a Select Case to determine the error type. Also
"IOException" says a lot more than "12345".
Exception handling fits well into the structure of the code, while in
VB6 error handling you have to jump back and forth in the code.
Spaghetti code is always harder to follow.
Todos Menos [MSFT] wrote:
in my opinion, vb6 error handler was much superior than this managed
crap.. i mean seriously-- it's a lot less verbose
Public Sub MySub
on error goto errhandler
CleanExit:
exit sub
ErrHandler:
Select Case Err.number
Case 12345, 1224334
resume cleanexit
case else
msgbox error$
resume cleanexit
end Select
End Sub
Ok something simple like int.Parse(string) can throw these exceptions:
ArgumentNullException, FormatException, OverflowException
I don't want my program to just crash on an exception, so I must
handle all of them. I don't care about which one happened, except to
write out exception.Message to a log file. It seems verbose to write
out three handlers that all do the same thing. So, I could just catch
Exception. But, is that recommended? It'll catch everything, even
out of memory exceptions.
What do you suggest?
Zytan

--
Göran Andersson
_____http://www.guffa.com- Hide quoted text -

- Show quoted text -

 

[Todos Menos [MSFT]]

re: and a bitch to figure out
what on earth is going on when it doesn't.

oh does the widdle baby programmer have a hard time following a widdle
goto statement

oh how cute

IT IS A GOTO STATEMENT DUDE. HOW MUCH SIMPLER CAN YOU GET?

 

[Paul]

First off,

We should try and avoid exceptions where possible

And as far as int parsing try something like this

#region isInteger
/// <summary>
/// Determines if it is a valid integer.
/// </summary>
/// <param name="var"></param>
/// <returns></returns>
public static bool isInteger(string var)
{
double result;

return (Double.TryParse(var,
System.Globalization.NumberStyles.Integer,
System.Globalization.NumberFormatInfo.CurrentInfo,
out result));
}
#endregion

#region -- intFromString --
/// <summary>
/// Safely casts a string as integer. If the string is not a valid
int NOT_INITIALISED_INT is returned.
/// </summary>
/// <param name="var">string to attempt parse on</param>
/// <param name="iDefault">int - Default to use if the string is not
a valid int</param>
/// <returns>int</returns>
public static int intFromString( string var )
{
return intFromString( var, NOT_INITIALISED_INT );
}

/// <summary>
/// Safely casts a string as integer. If the string is not a valid
int the default value is used.
/// </summary>
/// <param name="var">string to attempt parse on</param>
/// <param name="iDefault">int - Default to use if the string is not
a valid int</param>
/// <returns>int</returns>
public static int intFromString( string var, int iDefault )
{
if( isInteger( var ) )
{
return int.Parse( var );
}

return iDefault;
}
#endregion

That should get you by safely.
And if you care to test that over 100k iterations against a try catch
you will see why it is worth the effort.

On the error handling front,
In a web application we use a HttpModule with a configurable level of
reporting

This allows us to essential switch it up to maximum reporting level
during the first phase of deployment.
This is obviously slower and puts a greater load on the server, but
allows us to track and remove bugs.

This is only my opinion
After 10 years of developing commercial systems that interact with 3rd
parties I have to say that exceptions
are unavoidable but predictable. You should not be looking to trap
developer errors, these should be caught and fixed during
UAT ( this also goes if you are writing libray code for other
people ).
Rather you should be looking to cater for errors in comms failure
between your external interfaces and 3rd party software
(this includes importing files )

Hope this helps

 

[Todos Menos [MSFT]]

re:
Also as note... each try/catch block
is expensive so try to minimze them, and check your parameters before
you
execute.


yeah you're right

if Microsoft gave a damn about performance they never would have
invented .NET

 

[Jon Skeet [C# MVP]]

yes as Goran says its better to safe, than sorry.. but again what I gave is
unexpected situations at a global level.. That is provided by the .NET
environment, for windows applications. Also as note... each try/catch block
is expensive so try to minimze them, and check your parameters before you
execute.

try/catch blocks aren't expensive - it's only when exceptions are
*thrown* that there's any significant expense. Even that expense is
generally vastly overestimated by most people.

It's good practice to check parameters anyway, as then the *exact*
reason is apparent, and you can make sure that you don't "half"
complete an action. However, the correct response to incorrect
parameters is usually to throw an exception anyway...

See http://pobox.com/~skeet/csharp/exceptions.html and
http://pobox.com/~skeet/csharp/exceptions2.html
for more information.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

if Microsoft gave a damn about performance they never would have
invented .NET

It's true that object oriented languages are not primarily targeted on
speed, but C# performs quite well never the less. It's for example
generally 2-3 times faster than Java.

 

[Barry Kelly]

It's true that object oriented languages are not primarily targeted on
speed, but C# performs quite well never the less. It's for example
generally 2-3 times faster than Java.

Don't feed the trolls!

-- Barry

 

[Jon Skeet [C# MVP]]

It's true that object oriented languages are not primarily targeted on
speed, but C# performs quite well never the less. It's for example
generally 2-3 times faster than Java.

That's rubbish. Java and .NET generally perform roughly equivalently.
Java has been in the same ballpark as native code (eg 0-20% slower) for
quite a long time, so unless you're suggesting that .NET runs 2-3 times
faster than native code...

There are certainly areas where .NET outperforms Java. There are areas
where Java outperforms .NET. However, you'd have to pick an area where
Java is *really, really* poor and make that the bottleneck to get a 2-3
times speed improvement by using .NET.

 

[Todos Menos [MSFT]]

Bruce

whatever kid


I just don't accept mediocrity.
I don't accept an IDE that takes 120 seconds to open up.. on a core 2
duo laptop

sue me-- I just know that Microsoft can do BETTER

they did do BETTER-- it is called VB6

with Vb6 I could use one code base for clientside DHTML, server side
ASP; DTS; Excel, Outlook, Access and VBS.

Can VB.net do _ANY_ of those things?

I mean-- get real buddy

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

That's rubbish. Java and .NET generally perform roughly equivalently.
Java has been in the same ballpark as native code (eg 0-20% slower) for
quite a long time, so unless you're suggesting that .NET runs 2-3 times
faster than native code...

There are certainly areas where .NET outperforms Java. There are areas
where Java outperforms .NET. However, you'd have to pick an area where
Java is *really, really* poor and make that the bottleneck to get a 2-3
times speed improvement by using .NET.

Perhaps it's rubbish. I based my statement on these tests:
http://dada.perl.it/shootout/

In all the tests that I looked at, except exception handing, C# was 2-3
times faster than Java.

I see now that it's been a while since the last update, so newer
versions of Java might perform much better. I know that never versions
of C# performs better.

 

[Todos Menos [MSFT]]

who gives a crap about Java! they're a $3 billion market cap.. Atari
could buy Sun!

Microsoft had the msot popular language in the world; they killed it.
FOR NO REASON. WITHOUT A REPLACEMENT.

AND THIS SEE-SHARP CRAP? it was never invented!
AND THIS SEE-SHARP CRAP? it was never invented!
AND THIS SEE-SHARP CRAP? it was never invented!

 

[Todos Menos [MSFT]]

they sold us car that is incompatible with existing highways!

it doesn't 'go faster' it isn't compatible

I've never had a performance problem with Vb6.. why in the hell would
they make US change langauges?

you guys are the dipshits that bet on the wrong team. Java is dead; it
always has been. VB won the war.

C# is for wimps that are too trendy to use a real language
just because C has had a _CRAP_ interface for a decade-- does this
mean that VB goes away as soon as C gets a decent interface?

ROFL

C# is for kids; MS didn't need a 'kids programming language'

VB works in DTS, Clientside DHTML-- when you guys can run C# on the
clientside is when your langauge has a leg to stand on

as it is; I can cut and paste code between DHTML, ASP, Excel, Access,
Outlook, VBS

can C# do _ANY_ of those thigns?

Why would I want to use 5 languages when ONE works just fine

TAKE THIS LANGUAGE AND SHOVE IT!

 

[Todos Menos [MSFT]]

Java and .NET both run to slow IN DEVELOPMENT because neither is
compatible with Vb6

 

[Jon Skeet [C# MVP]]

Perhaps it's rubbish. I based my statement on these tests:
http://dada.perl.it/shootout/

In all the tests that I looked at, except exception handing, C# was 2-3
times faster than Java.

I see now that it's been a while since the last update, so newer
versions of Java might perform much better. I know that never versions
of C# performs better.

The code shown doesn't show the loops being timed, so my guess is that
it's the *total* CPU time for the whole program.

One area where Java certainly *is* worse is startup time. If that's
being included in the total time, then the results are a farce - most
programs *don't* run for subsecond times.

It also doesn't appear to allow for JIT warmup, which again would bias
things massively.

Of course, if the methodology page were up, we'd have some more idea
about this...

I'll have a go at putting some of the code provided into a more
reasonable benchmarking framework, and we'll see what the results are.
Java certainly *isn't* 2-3 times slower than C# - but there are some
*very* bad benchmarks out there.

 

[Jon Skeet [C# MVP]]

I'll have a go at putting some of the code provided into a more
reasonable benchmarking framework, and we'll see what the results are.
Java certainly *isn't* 2-3 times slower than C# - but there are some
*very* bad benchmarks out there.

Okay, I've got the nested loop test in a better shape. This one showed
CPU of 0.28 for C# and 0.85 for Java on the web page, so C# appears to
be three times faster, right? Well, let's try a more balanced test...

Java code:
public class NestedLoop
{
public static void main(String[] args)
{
int iterations = Integer.parseInt(args[0]);
int loop = Integer.parseInt(args[1]);

long total = 0;
long start = System.currentTimeMillis();
for (int i=0; i < iterations; i++)
{
total += test(loop);
}
long end = System.currentTimeMillis();
System.out.println ("Total time (ms): "+(end-start));
System.out.println ("Running total: "+total);
}

public static int test(int n)
{
int x=0;
for (int a=0; a<n; a++)
for (int b=0; b<n; b++)
for (int c=0; c<n; c++)
for (int d=0; d<n; d++)
for (int e=0; e<n; e++)
for (int f=0; f<n; f++)
x++;
return x;
}
}

C# code:
using System;

public class NestedLoop
{
public static void Main(string[] args)
{
int iterations = int.Parse(args[0]);
int loop = int.Parse(args[1]);

long total = 0;
DateTime start = DateTime.Now;
for (int i=0; i < iterations; i++)
{
total += Test(loop);
}
DateTime end = DateTime.Now;
Console.WriteLine ("Total time (ms): "+
(end-start).TotalMilliseconds);
Console.WriteLine ("Running total: "+total);
}

public static int Test(int n)
{
int x=0;
for (int a=0; a<n; a++)
for (int b=0; b<n; b++)
for (int c=0; c<n; c++)
for (int d=0; d<n; d++)
for (int e=0; e<n; e++)
for (int f=0; f<n; f++)
x++;
return x;
}
}


Points to note:
1) My results are taken given suitably large numbers, so that the Java
JIT has time to "warm up" (i.e. re-optimise), and so that timing
granularity is irrelevant (so it doesn't matter that I'm not using
StopWatch in .NET).

2) We're only testing the time take to do the actual looping (and
method call) rather than including the startup time (which I believe to
be the main cause of bias in the web results)

3) We're measuring elapsed time rather than CPU time. However, the
tests were conducted on an idle box (admittedly Vista, which is never
completely idle!) and shot up to 100% during the tests - I don't think
the difference would be significant.

So, results on my laptop (C# 2, .NET 3, Java 1.6):

C:\Users\Jon\Test>java NestedLoop 1000 15
Total time (ms): 27188
Running total: 11390625000

C:\Users\Jon\Test>nestedloop 1000 15
Total time (ms): 37154.8485
Running total: 11390625000

In other words, C#: 37s, Java: 27s.
Instead of Java being shown to be 3 times *slower* in this test, it's
actually 25% faster.

I don't plan to repeat this for all the other tests on the web page,
but hopefully that shows you just how much stock you should put in
their testing methodology.