about try and catch

[BC]

Hi all,

I have a method that accepts a string as the parameter. This can be a
base64 image string, or just a normal string. Currently to test whether
it's a image string or just a normal string, I used try and catch:

private void MyMethod(string str){
try{
// If not exception is cought, then it is an image string
MemoryStream stream = new MemoryStream(Convert.FromBase64String(str));
Bitmap bitmap = new Bitmap(stream);
...
}
catch{
// If exception is cought, then I assumed it is a normal string
string normalStr = str;
...
}
}

The codes work fine and gave me what I want. However, some while ago an
article I read mentioned that using try and catch could slow down
performance. My question is that if I don't use try and catch to test
the string, what is the alternative ways I can do this? Also, about the
performance thing, how true is it?
Cheers,

Benny

*** Sent via Developersdex http://www.developersdex.com ***

[Maqsood Ahmed]

Hello,
Yes using try catch to check the validity of data is not a good idea.
I think you should have a boolean value as a parameter also. to indicate
that if the string is Base64 or a normal string. I prefer to use a code
like this..

public void MyMethod(string paramString,bool bIsBase64String)
{
if(bIsBase64String)
{
MemoryStream stream = new
MemoryStream(Convert.FromBase64String(paramString) );
Bitmap bitmap = new Bitmap(stream);
}
else
{
string theString = paramString; //You don't have to do it.. you
can use the paramString instead ;)
//Your code...
}
}
}

HTH. Cheers :)
Maqsood Ahmed [MCP,C#]
Kolachi Advanced Technologies
http://www.kolachi.net

*** Sent via Developersdex http://www.developersdex.com ***

[BC]

Hi Maqsood,

Thanks for the suggestion. However the thing is I am reading the string
from a resource file (XML file) from a third party. Therefore I have no
idea whether the string is an image string or just a normal string
before hand.

Any other ideas?
Cheers,

Benny

*** Sent via Developersdex http://www.developersdex.com ***

[Michael C]

"BC" <no****@devdex.com> wrote in message
news:ev****************@TK2MSFTNGP14.phx.gbl...

The codes work fine and gave me what I want. However, some while ago an
article I read mentioned that using try and catch could slow down
performance. My question is that if I don't use try and catch to test
the string, what is the alternative ways I can do this? Also, about the
performance thing, how true is it?

The only way to not use try catch is to check if it is a base64 string or
not in some way. I'm not sure if that way exists or not but if you can't
find it then all you can do is use try catch. Performance is not too much of
a problem, you can trap several thousand exceptions per second. The
performace becomes a problem if you catch a lot of exceptions in a tight
loop it could make the loop hundreds or thousands of times slower. Depends
how often you are calling your function and how long it takes if it succeeds
I guess.

Michael

[Jon Skeet [C# MVP]]

BC <no****@devdex.com> wrote:

I have a method that accepts a string as the parameter. This can be a
base64 image string, or just a normal string. Currently to test whether
it's a image string or just a normal string, I used try and catch:

private void MyMethod(string str){
try{
// If not exception is cought, then it is an image string
MemoryStream stream = new MemoryStream(Convert.FromBase64String(str));
Bitmap bitmap = new Bitmap(stream);
...
}
catch{
// If exception is cought, then I assumed it is a normal string
string normalStr = str;
...
}
}

The codes work fine and gave me what I want. However, some while ago an
article I read mentioned that using try and catch could slow down
performance. My question is that if I don't use try and catch to test
the string, what is the alternative ways I can do this? Also, about the
performance thing, how true is it?

While exceptions aren't hugely cheap, they're not nearly as expensive
as they're made out to be. If there were methods to check whether or
not a stream actually contained an image, and whether or not a string
was a valid base 64 string that would be preferrable from a readability
point of view, but unless exceptions are being thrown a *lot*, they're
unlikely to have any significant performance impact.

Of course, you could do a very quick check first - if the length of the
string isn't a multiple of 4, then it *definitely* isn't a base64
string. If you have a lot of non-base64 strings that could make some
difference.

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

[StealthyMark]

"BC" wrote:

I have a method that accepts a string as the parameter. This can be a
base64 image string, or just a normal string. Currently to test whether
it's a image string or just a normal string, I used try and catch:

private void MyMethod(string str){
try{
// If not exception is cought, then it is an image string
MemoryStream stream = new MemoryStream(Convert.FromBase64String(str));
Bitmap bitmap = new Bitmap(stream);
...
}
catch{
// If exception is cought, then I assumed it is a normal string
string normalStr = str;
...
}
}

I'm assuming you have two possibilities:
1) Your string is a base64 encoded stream
2) Your string is a path to an image file

If that's the case, you can use the following code:

private Bitmap MyMethod(string str)
{
if (File.Exists(str))
// we have a file
return new Bitmap(str)

// we have an base64 encoded image
MemoryStream stream = new MemoryStream(Convert.FromBase64String(str));
returm new Bitmap(stream);
}

[David Levine]

>

While exceptions aren't hugely cheap, they're not nearly as expensive
as they're made out to be.

I disagree, they can be very expensive, but this aspect of it has been
overhyped - many applications are simply not affected by the performance
hit.

I believe that correct program behavior is more important than squeezing a
few more cycles from a processing path, and that improvements in processor
speed and design, and future changes to the CLR runtime, can speed up
exception handling speeds a great deal.

One reason why exception processing is slow is that AFAIK all exceptions get
routed through the kernel and back to the Win32 subsystem before the CLR
actually starts processing it - processor caches get flushed, ring
transitions occur, etc. - this will always be slow. Perhaps one day the CLR
will check the stack of the faulting thread to determine if it needs to
route it through the kernel (e.g. if part of the thread winds through
unmanaged code), and if not, handle the whole thing locally.

I don't know what changes have been made to this part of the runtime in
Whidbey so I don't know much that aspect of it has changed.

regards,
Dave

[goody8]

On Fri, 29 Apr 2005 03:08:04 -0700, StealthyMark
<St**********@discussions.microsoft.com> wrote:

"BC" wrote:

I have a method that accepts a string as the parameter. This can be a
base64 image string, or just a normal string. Currently to test whether
it's a image string or just a normal string, I used try and catch:

private void MyMethod(string str){
try{
// If not exception is cought, then it is an image string
MemoryStream stream = new MemoryStream(Convert.FromBase64String(str));
Bitmap bitmap = new Bitmap(stream);
...
}
catch{
// If exception is cought, then I assumed it is a normal string
string normalStr = str;
...
}
}

I'm assuming you have two possibilities:
1) Your string is a base64 encoded stream
2) Your string is a path to an image file

If that's the case, you can use the following code:

private Bitmap MyMethod(string str)
{
if (File.Exists(str))
// we have a file
return new Bitmap(str)

// we have an base64 encoded image
MemoryStream stream = new MemoryStream(Convert.FromBase64String(str));
returm new Bitmap(stream);
}

The original poster was worried about his try-catch being too slow. I
would think that calling File.Exists would be a LOT slower than the
try-catch mechanism - it has to go to the disk, maybe multiple times,
and search the directory.