Exception handling suggestions

[Zytan]

Ok something simple like int.Parse(strin g) can throw these exceptions:
ArgumentNullExc eption, FormatException , OverflowExcepti on

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.Messa ge 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

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

Todos Menos [MSFT] wrote:

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
On Mar 13, 3:06 pm, Göran Andersson <[e-mail] wrote:

>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 (FormatExceptio n) {
} 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
On Mar 10, 3:46 pm, "Zytan" <zytanlith...@y ahoo.comwrote:
Ok something simple like int.Parse(strin g) can throw these exceptions:
ArgumentNull Exception, FormatException , OverflowExcepti on
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.Messa ge 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 -

--
Göran Andersson
_____
http://www.guffa.com

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

Todos Menos [MSFT] wrote:

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


On Mar 13, 1:37 pm, Göran Andersson <[e-mail] wrote:

>Zytan wrote:

>>Note it uses
Application.T hreadException += new ...
instead of your
AppDomain.Cur rentDomain.Unha ndledException +=new ...
You mentioned ThreadException , but now I'm confused. Why do these
both do the same thing?

UnhandledExcep tion catches any unhandled exception in the application,
while ThreadException only catches unhandled exceptions that occur in
Windows Forms threads.

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

--
Göran Andersson
_____
http://www.guffa.com

[Bruce Wood]

On Mar 13, 11:24 pm, Göran Andersson <[e-mail] wrote:

Todos Menos [MSFT] wrote:

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.

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 fucking 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

On Mar 13, 11:24 pm, Göran Andersson <[e-mail] wrote:

Todos Menos [MSFT] wrote:

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

On Mar 13, 1:37 pm, Göran Andersson <[e-mail] wrote:

Zytan wrote:
Note it uses
Application.Th readException += new ...
instead of your
AppDomain.Curr entDomain.Unhan dledException +=new ...
You mentioned ThreadException , but now I'm confused. Why do these
both do the same thing?
UnhandledExcept ion catches any unhandled exception in the application,
while ThreadException only catches unhandled exceptions that occur in
Windows Forms threads.

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

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

- Show quoted text -

[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 FUCKING _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..



On Mar 13, 11:09 pm, Göran Andersson <[e-mail] wrote:

Todos Menos [MSFT] wrote:

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

On Mar 13, 3:06 pm, Göran Andersson <[e-mail] wrote:

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 (FormatExceptio n) {
} 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
"IOExceptio n" 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
On Mar 10, 3:46 pm, "Zytan" <zytanlith...@y ahoo.comwrote:
Ok something simple like int.Parse(strin g) can throw these exceptions:
ArgumentNullE xception, FormatException , OverflowExcepti on
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.Messa ge 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 -

--
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

On Mar 13, 11:09 pm, Göran Andersson <[e-mail] wrote:

Todos Menos [MSFT] wrote:

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

On Mar 13, 3:06 pm, Göran Andersson <[e-mail] wrote:

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 (FormatExceptio n) {
} 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
"IOExceptio n" 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
On Mar 10, 3:46 pm, "Zytan" <zytanlith...@y ahoo.comwrote:
Ok something simple like int.Parse(strin g) can throw these exceptions:
ArgumentNullE xception, FormatException , OverflowExcepti on
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.Messa ge 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 -

--
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?
On Mar 13, 1:57 pm, "Bruce Wood" <brucew...@cana da.comwrote:

On Mar 13, 1:36 pm, "Todos Menos [MSFT]"

<todos_menos_m. [e-mail] rote:

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

Well, yeah, sort of in the same way that GOTO is much less verbose
than all of this complicated for / foreach / while garbage. Don't even
get me started about all of those wordy function headers with
parameters and stuff... when you can just make everything global and
access it from anywhere. :-)

The problem with VB6 error handling is that at _any_ point in your
code, control can magically jump to your error handler subroutine
(hey, the syntax even _says_ goto), run some code, and then slip
quietly back into the control flow of your program as if nothing
happened.

Just like GOTO, it's great when it works, and a bitch to figure out
what on earth is going on when it doesn't. Like GOTO it can be used
responsibly to great effect, or horribly abused to create
incomprehensibl e code.

Been there, done that. I'm happier with the way things work in .NET,
thanks.- Hide quoted text -

- Show quoted text -

[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(strin g var)
{
double result;

return (Double.TryPars e(var,
System.Globaliz ation.NumberSty les.Integer,
System.Globaliz ation.NumberFor matInfo.Current Info,
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">stri ng 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">stri ng 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

On Mar 11, 7:23 am, "VJ" <nonewsaddr...@ yahoo.comwrote:

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.

For a console app.. not sure if there one such, my expertise is limited
there..sorry i cant help much.

VJ

"Zytan" <zytanlith...@y ahoo.comwrote in message

news:11******** **************@ j27g2000cwj.goo glegroups.com.. .

If the string really can be null, that is easy to check for. You should
check that before calling the method instead of waiting for the exception.

Actually, I just do:
int result = int.Parse("0" + s);
so, nulls are handled already.

I'm concerned with s == "ABC". The data that s can be may be warped
sometimes, and this is actually a decent spot to check to ensure it is
not warped.

If you don't really need to determine the exact reason why the string
can't be converted, you can use the int.TryParse method instead. Then
you will not need any exception handling at all.

Ah, ok, thanks, Göran!

Zytan

[Jon Skeet [C# MVP]]

VJ <no***********@ yahoo.comwrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too