473,854 Members | 1,401 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

The problem with Try Catch Finally...

Variable scope doesn't make sense to me when it comes to Try Catch Finally.

Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim them
"on the fly" only if needed (save as much resources as possible). A little
further... I may wish to create a sqlcommand and datareader object ONLY if
certain conditions are met. But, if I want to clean these up in the Finally
then I am FORCED to declare them above the Try.

Why???
Nov 17 '05 #1
23 3093
Why not declare them and just CREATE them when you need to. After all,
that's what may take the longest.

- Jeff

"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:#$******** ******@TK2MSFTN GP12.phx.gbl...
Variable scope doesn't make sense to me when it comes to Try Catch Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim them "on the fly" only if needed (save as much resources as possible). A little
further... I may wish to create a sqlcommand and datareader object ONLY if
certain conditions are met. But, if I want to clean these up in the Finally then I am FORCED to declare them above the Try.

Why???

Nov 17 '05 #2
Well, you are most of the way there in your description. Variables are local
to the scope they are declared in, and scope is determined by code block.
Any time you have a code block, you can declare local variables in that
block. This is true for try - catch - finally, if, while, or anything other
similar construct. This enables you to declare a new variable inside that
block, and have it marked for GC once you exit that code block.

What it means for you in terms of your try - catch is that you need to code
around how you create it. First of all, declaring a variable doesn't
allocate space for it, so you don't have to worry about that. You may also
want to re-think what you are enclosing in a try-catch block. You don't need
to wrap huge chuck of code in such a block - you just need to wrap a
dangerous operation that might throw an exception in such a block. So,
declare, prepare, then when you execute the risky operation, wrap it in a
try-catch. I seldom have more than a couple of lines of code in a try block,
and usually have exactly one.

--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Variable scope doesn't make sense to me when it comes to Try Catch Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim them "on the fly" only if needed (save as much resources as possible). A little
further... I may wish to create a sqlcommand and datareader object ONLY if
certain conditions are met. But, if I want to clean these up in the Finally then I am FORCED to declare them above the Try.

Why???

Nov 17 '05 #3
> You mentioned "I seldom have more than a couple of lines of code in a try
block, and usually have exactly one." Is this standard? In VB6 I've always

No, that is not the standard. I, for example, will put all of the code in a
method inside a try/catch block, and then put additional try/catch blocks
and conditional code inside that outer block to catch specific errors. The
outside one is for anything I might have missed. How you use it is up to
you, and what your needs are.
What is considered "risky operation"? Connecting to db, filling datasets,
datareaders, etc...?
That's a difficult question to answer (which is why I wrap all of my method
code in an outer try/catch block). Any operation which might cause your
program to malfunction is risky.

The bottom line is (and everyone here seems to agree on this), declare your
variables outside of the block, and assign them inside the block.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Complex things are made up of
lots of simple things.
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. .. Very interesting response.

You mentioned "I seldom have more than a couple of lines of code in a try
block, and usually have exactly one." Is this standard? In VB6 I've always coded using "On Error Goto errHandler, etc..." which wraps all the code into the trap. Do I have to need a paradigm shift? How do I handle errors
outside of the Try statement?

What is considered "risky operation"? Connecting to db, filling datasets,
datareaders, etc...?

"Chris Jackson" <ch****@mvps.or g> wrote in message
news:ek******** *****@TK2MSFTNG P12.phx.gbl...
Well, you are most of the way there in your description. Variables are local
to the scope they are declared in, and scope is determined by code block.
Any time you have a code block, you can declare local variables in that
block. This is true for try - catch - finally, if, while, or anything

other
similar construct. This enables you to declare a new variable inside that block, and have it marked for GC once you exit that code block.

What it means for you in terms of your try - catch is that you need to

code
around how you create it. First of all, declaring a variable doesn't
allocate space for it, so you don't have to worry about that. You may also want to re-think what you are enclosing in a try-catch block. You don't

need
to wrap huge chuck of code in such a block - you just need to wrap a
dangerous operation that might throw an exception in such a block. So,
declare, prepare, then when you execute the risky operation, wrap it in a try-catch. I seldom have more than a couple of lines of code in a try

block,
and usually have exactly one.

--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Variable scope doesn't make sense to me when it comes to Try Catch

Finally.

Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to
dim them
"on the fly" only if needed (save as much resources as possible). A

little further... I may wish to create a sqlcommand and datareader object
ONLY if certain conditions are met. But, if I want to clean these up in the

Finally
then I am FORCED to declare them above the Try.

Why???



Nov 17 '05 #4
And one other thing I should mention, in case you don't understand. The
problem you experienced was due to referencing variables declared inside the
try/catch block from the Finally block. The Finally block executes
regardless of whether an error occurs or not. That means that it must be
able to access the variables used in it regardless of whether they were
assigned or not. When you declare a variable inside the try block, your code
might never reach the declaration before execution falls through to the
catch block. Therefore, any variable referenced in the Finnally block must
be declared prior to the Try block.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Complex things are made up of
lots of simple things.

"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Very interesting response.

You mentioned "I seldom have more than a couple of lines of code in a try
block, and usually have exactly one." Is this standard? In VB6 I've always coded using "On Error Goto errHandler, etc..." which wraps all the code into the trap. Do I have to need a paradigm shift? How do I handle errors
outside of the Try statement?

What is considered "risky operation"? Connecting to db, filling datasets,
datareaders, etc...?

"Chris Jackson" <ch****@mvps.or g> wrote in message
news:ek******** *****@TK2MSFTNG P12.phx.gbl...
Well, you are most of the way there in your description. Variables are local
to the scope they are declared in, and scope is determined by code block.
Any time you have a code block, you can declare local variables in that
block. This is true for try - catch - finally, if, while, or anything

other
similar construct. This enables you to declare a new variable inside that block, and have it marked for GC once you exit that code block.

What it means for you in terms of your try - catch is that you need to

code
around how you create it. First of all, declaring a variable doesn't
allocate space for it, so you don't have to worry about that. You may also want to re-think what you are enclosing in a try-catch block. You don't

need
to wrap huge chuck of code in such a block - you just need to wrap a
dangerous operation that might throw an exception in such a block. So,
declare, prepare, then when you execute the risky operation, wrap it in a try-catch. I seldom have more than a couple of lines of code in a try

block,
and usually have exactly one.

--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Variable scope doesn't make sense to me when it comes to Try Catch

Finally.

Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to
dim them
"on the fly" only if needed (save as much resources as possible). A

little further... I may wish to create a sqlcommand and datareader object
ONLY if certain conditions are met. But, if I want to clean these up in the

Finally
then I am FORCED to declare them above the Try.

Why???



Nov 17 '05 #5
Folks, I cant beleive how long this thread has become !

When we are old and grey, we can enchant our grandchildren with stories of
how we spent our precious youth talking about Try Catch blocks !

Sorry, couldnt resist that, keep smiling :)

"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Variable scope doesn't make sense to me when it comes to Try Catch Finally.
Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim them "on the fly" only if needed (save as much resources as possible). A little
further... I may wish to create a sqlcommand and datareader object ONLY if
certain conditions are met. But, if I want to clean these up in the Finally then I am FORCED to declare them above the Try.

Why???

Nov 17 '05 #6
Good stuff! :)

"Terry Burns" <te*********@BT Openworld.com> wrote in message
news:OX******** ******@TK2MSFTN GP09.phx.gbl...
Folks, I cant beleive how long this thread has become !

When we are old and grey, we can enchant our grandchildren with stories of
how we spent our precious youth talking about Try Catch blocks !

Sorry, couldnt resist that, keep smiling :)

"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Variable scope doesn't make sense to me when it comes to Try Catch

Finally.

Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to dim

them
"on the fly" only if needed (save as much resources as possible). A little further... I may wish to create a sqlcommand and datareader object ONLY if certain conditions are met. But, if I want to clean these up in the

Finally
then I am FORCED to declare them above the Try.

Why???


Nov 17 '05 #7
A risky operation is anything that could raise an exception. When calling a
method check the help on it. It will list any exceptions that it raised and
the conditions to cause the exception.

Anytime a risky operation is called place it in the try block, and in the
finally block clean up any resources such as filestreams, database
connections, references to COM objects, etc... In the catch block you
could...

1) propagate the error to the caller
2) wrap that error in a new custom (InnerException ) error of your own giving
a more human understandable message and throw to caller
3) log the error and continue with rest of method
4) ignore and do again (entire try-catch-finally in a loop).
5) ignore the error and continue with rest of method.
6) ?? anything you desire

What you do depends on the needs/requirements of your application.

--
Michael Lang, MCSD
See my .NET open source projects
http://sourceforge.net/projects/dbobjecter (code generator)
http://sourceforge.net/projects/genadonet ("generic" ADO.NET)

"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Very interesting response.

You mentioned "I seldom have more than a couple of lines of code in a try
block, and usually have exactly one." Is this standard? In VB6 I've always coded using "On Error Goto errHandler, etc..." which wraps all the code into the trap. Do I have to need a paradigm shift? How do I handle errors
outside of the Try statement?

What is considered "risky operation"? Connecting to db, filling datasets,
datareaders, etc...?

"Chris Jackson" <ch****@mvps.or g> wrote in message
news:ek******** *****@TK2MSFTNG P12.phx.gbl...
Well, you are most of the way there in your description. Variables are local
to the scope they are declared in, and scope is determined by code block.
Any time you have a code block, you can declare local variables in that
block. This is true for try - catch - finally, if, while, or anything

other
similar construct. This enables you to declare a new variable inside that block, and have it marked for GC once you exit that code block.

What it means for you in terms of your try - catch is that you need to

code
around how you create it. First of all, declaring a variable doesn't
allocate space for it, so you don't have to worry about that. You may also want to re-think what you are enclosing in a try-catch block. You don't

need
to wrap huge chuck of code in such a block - you just need to wrap a
dangerous operation that might throw an exception in such a block. So,
declare, prepare, then when you execute the risky operation, wrap it in a try-catch. I seldom have more than a couple of lines of code in a try

block,
and usually have exactly one.

--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
"VB Programmer" <gr*********@ go-intech.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Variable scope doesn't make sense to me when it comes to Try Catch

Finally.

Example: In order to close/dispose a db connection you have to dim the
connection outside of the Try Catch Finally block. But, I prefer to
dim them
"on the fly" only if needed (save as much resources as possible). A

little further... I may wish to create a sqlcommand and datareader object
ONLY if certain conditions are met. But, if I want to clean these up in the

Finally
then I am FORCED to declare them above the Try.

Why???



Nov 17 '05 #8
> > You mentioned "I seldom have more than a couple of lines of code in a
try
block, and usually have exactly one." Is this standard? In VB6 I've always
No, that is not the standard. I, for example, will put all of the code in

a method inside a try/catch block, and then put additional try/catch blocks
and conditional code inside that outer block to catch specific errors. The
outside one is for anything I might have missed. How you use it is up to
you, and what your needs are.


I would never go so far as to put all of the code inside of a method inside
of a try-catch block, because then you are never really sure what you are
catching. Sure, you could simply catch a System.Exceptio n, but if you don't
know what you're catching, and as a result can't react appropriately, you
probably don't want to just sit on that error instead of passing it up
through the call stack.

With VB6, you just had to universally set up an onerror statement that
caught all errors, and then go through and figure out what happened and what
to do about it. The beauty of try-catch is that you can wrap specific
statements and handle it appropriately.

Let's do an example - open up a SQL Server connection, set up a command
object, and execute that command object:

----
SqlConnection connMyConnectio n = new SqlConnection(s zConnectionStri ng);
SqlCommand cmdMyCommand = new SqlCommand("MyC ommand", connMyConnectio n);
cmdMyCommand .CommandType = CommandType.Sto redProcedure;
cmdMyCommand .Parameters.Add ("@myParameter" , SqlDbType.VarCh ar, 50).Value =
szValue;
connMyConnectio n.Open();
cmdMyCommand.Ex ecuteNonQuery() ;
----

The SqlConnection constructor that I used does not throw an exception, so
there is nothing to catch there.
The SqlCommand constructor that I used does not throw an exception, so there
is nothing to catch there.
Setting the command type could throw an ArgumentExcepti on, so you'll want to
catch that.
The add method of the parameters collection doesn't throw an exception, nor
does the Value property of the SqlParameter object, so there is nothing to
catch there.
The Open method of SqlConnection could throw either an
InvalidOperatio nException or a SqlException, so you'll want to catch that.
The ExecuteNonQuery method of SqlCommand could throw a SqlException, so
you'll want to catch that.

So, you end up with:

----
SqlConnection connMyConnectio n = new SqlConnection(c onnectionString );
SqlCommand cmdMyCommand = new SqlCommand("MyC ommand", connMyConnectio n);
try {
cmdMyCommand .CommandType = CommandType.Sto redProcedure;
} catch (ArgumentExcept ion myArgumentExcep tion) {
// do something to react to this - since it's hard coded, you can
probably fix your code and get rid of this check
} finally {
// do some cleanup work
}
cmdMyCommand .Parameters.Add ("@myParameter" , SqlDbType.VarCh ar, 50).Value =
szValue;
try {
connMyConnectio n.Open();
} catch (InvalidOperati onException myInvalidOperat ionException) {
// do something to react to this - since it's hard coded, again you can
probably fix your code and dispense with this check
} catch (SqlException mySqlException1 ) {
// do something to react to this - either dump to the event log or, if
in debug mode (use preprocessors) write back the message
} finally {
// do some cleanup work
}
try {
cmdMyCommand.Ex ecuteNonQuery() ;
} catch (SqlException mySqlException2 ) {
// do something to react to this - either dump to the event log or, if
in debug mode (use preprocessors) write back the message
} finally {
// do some cleanup work
}
----

If you look up the best practices, you will find it stated in as many words:

"Use try/finally blocks around code that can potentially generate an
exception and centralize your catch statements in one location. In this way,
the try statement generates the exception, the finally statement closes or
deallocates resources, and the catch statement handles the exception from a
central location."

Full list of best practices here:

http://msdn.microsoft.com/library/de...exceptions.asp

So yes, I would beg to differ. I do consider this a standard. It's what I've
been doing in C++ for years now.

Also, you can check for exceptions before they are thrown. If you are going
to close the aforementioned SqlConnection, instead of just using:

connMyConnectio n.Close();

use:

if (connMyConnecti on != null && connMyConnectio n.State !=
ConnectionState .Closed) {
connMyConnectio n.Close();
}

And so it goes.
--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--
Nov 17 '05 #9
> I would never go so far as to put all of the code inside of a method
inside
of a try-catch block, because then you are never really sure what you are
catching. Sure, you could simply catch a System.Exceptio n, but if you don't know what you're catching, and as a result can't react appropriately, you
probably don't want to just sit on that error instead of passing it up
through the call stack.

I'm always sure of what I'm catching, because I use a global error-handler
routine in my outer try/catch block, which logs the Exception message, any
InnerException message, and a Stack trace to the Event Log. This is so that
I can figure out what caused the error and determine how to best handle it
with code.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Complex things are made up of
lots of simple things.

"Chris Jackson" <ch****@mvps.or g> wrote in message
news:uJ******** ******@TK2MSFTN GP12.phx.gbl...
You mentioned "I seldom have more than a couple of lines of code in a try block, and usually have exactly one." Is this standard? In VB6 I've

always
No, that is not the standard. I, for example, will put all of the code in a
method inside a try/catch block, and then put additional try/catch
blocks and conditional code inside that outer block to catch specific errors. The outside one is for anything I might have missed. How you use it is up to
you, and what your needs are.


I would never go so far as to put all of the code inside of a method

inside of a try-catch block, because then you are never really sure what you are
catching. Sure, you could simply catch a System.Exceptio n, but if you don't know what you're catching, and as a result can't react appropriately, you
probably don't want to just sit on that error instead of passing it up
through the call stack.

With VB6, you just had to universally set up an onerror statement that
caught all errors, and then go through and figure out what happened and what to do about it. The beauty of try-catch is that you can wrap specific
statements and handle it appropriately.

Let's do an example - open up a SQL Server connection, set up a command
object, and execute that command object:

----
SqlConnection connMyConnectio n = new SqlConnection(s zConnectionStri ng);
SqlCommand cmdMyCommand = new SqlCommand("MyC ommand", connMyConnectio n);
cmdMyCommand .CommandType = CommandType.Sto redProcedure;
cmdMyCommand .Parameters.Add ("@myParameter" , SqlDbType.VarCh ar, 50).Value = szValue;
connMyConnectio n.Open();
cmdMyCommand.Ex ecuteNonQuery() ;
----

The SqlConnection constructor that I used does not throw an exception, so
there is nothing to catch there.
The SqlCommand constructor that I used does not throw an exception, so there is nothing to catch there.
Setting the command type could throw an ArgumentExcepti on, so you'll want to catch that.
The add method of the parameters collection doesn't throw an exception, nor does the Value property of the SqlParameter object, so there is nothing to
catch there.
The Open method of SqlConnection could throw either an
InvalidOperatio nException or a SqlException, so you'll want to catch that.
The ExecuteNonQuery method of SqlCommand could throw a SqlException, so
you'll want to catch that.

So, you end up with:

----
SqlConnection connMyConnectio n = new SqlConnection(c onnectionString );
SqlCommand cmdMyCommand = new SqlCommand("MyC ommand", connMyConnectio n);
try {
cmdMyCommand .CommandType = CommandType.Sto redProcedure;
} catch (ArgumentExcept ion myArgumentExcep tion) {
// do something to react to this - since it's hard coded, you can
probably fix your code and get rid of this check
} finally {
// do some cleanup work
}
cmdMyCommand .Parameters.Add ("@myParameter" , SqlDbType.VarCh ar, 50).Value = szValue;
try {
connMyConnectio n.Open();
} catch (InvalidOperati onException myInvalidOperat ionException) {
// do something to react to this - since it's hard coded, again you can probably fix your code and dispense with this check
} catch (SqlException mySqlException1 ) {
// do something to react to this - either dump to the event log or, if
in debug mode (use preprocessors) write back the message
} finally {
// do some cleanup work
}
try {
cmdMyCommand.Ex ecuteNonQuery() ;
} catch (SqlException mySqlException2 ) {
// do something to react to this - either dump to the event log or, if
in debug mode (use preprocessors) write back the message
} finally {
// do some cleanup work
}
----

If you look up the best practices, you will find it stated in as many words:
"Use try/finally blocks around code that can potentially generate an
exception and centralize your catch statements in one location. In this way, the try statement generates the exception, the finally statement closes or
deallocates resources, and the catch statement handles the exception from a central location."

Full list of best practices here:

http://msdn.microsoft.com/library/de...exceptions.asp
So yes, I would beg to differ. I do consider this a standard. It's what I've been doing in C++ for years now.

Also, you can check for exceptions before they are thrown. If you are going to close the aforementioned SqlConnection, instead of just using:

connMyConnectio n.Close();

use:

if (connMyConnecti on != null && connMyConnectio n.State !=
ConnectionState .Closed) {
connMyConnectio n.Close();
}

And so it goes.
--
Chris Jackson
Software Engineer
Microsoft MVP - Windows XP
Windows XP Associate Expert
--

Nov 17 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
11081
by: Roger Redford | last post by:
Dear experts, I'm trying to learn java on my own. I picked up a sample online, but it is not compiling right: ------------------------------------------------ import java.io.*;
10
1468
by: RepStat | last post by:
If I have code such a SqConnection cndb = new SqlConnection(connstr) SqlDataReader dr = null tr cndb.Open() SqlCommand cmd = new SqlCommand("exec mysp", cndb) dr = cmd.ExecuteReader()
7
1733
by: Sean Kirkpatrick | last post by:
I got caught with my pants down the other day when trying to explain Try...Catch...Finally and things didn't work as I had assumed. Perhaps someone can explain to me the purpose of Finally. I've looked at several texts that I have and none of them address this specific point. If I call some method that throws an exception in my routine Foo, sub foo call bar <- throws an exception do something else <- never get here
8
1301
by: Rob Meade | last post by:
Hi all, Ok - typically, in a function that returns as a boolean, if there's a bit of database action going on I'll have a little tidy up process before exiting the function. I know .net is supposed to handle all of this stuff itself, but its a practice I've always performed, and personally I like to know its been done! So, as an example I'd have a little something like this..
6
7453
by: foolmelon | last post by:
If a childThread is in the middle of a catch block and handling an exception caught, the main thread calls childThread.Abort(). At that time a ThreadAbortException is thrown in the childThread. The question is: after the ThreadAbortException is thrown, does the childThread continue run the remaining code in the catch block?
5
2325
by: Morten Snedker | last post by:
The use of Try in the Finally part - is that overkill?. I think of the code failing before opening sqlCon - that would generate an error in the Finally part. How would Finally handle that? Try Dim cmd As New SqlCommand cmd.CommandText = "spSetAdLinks" cmd.CommandType = Data.CommandType.StoredProcedure cmd.Connection = sqlCon
0
2484
by: =?Utf-8?B?aGVyYmVydA==?= | last post by:
I read from a serialport using a worker thread. Because the worker thread t does not loop often, I cannot wait to terminate the worker thread using a boolean in the While condition. So I have a StopReader() method that simply aborts the worker thread (is there a better way for the above situation?). The StopReader creates an ObjectDisposedException when calling t.Abort(). WHY? Public Sub StopReader()
12
2701
by: David Lozzi | last post by:
Howdy, I ran into a very interesting issue and I'm curios as to how this is suppose to work. I am using Try...Catch...Finally statements for all database connectivity in my ASP.NET 2.0 web application. I'm connecting to IBM's Universe 10.2 using UniObjects.Net. Anyway, if the connection errors, the Finally closes the connection. What I see happening is that the function in the Finally statement either isn't running or doesn't apply what...
9
1961
by: TC | last post by:
Hey All, I posted this to the Crypto users group and forgot to add the VB.Net users group. I apologize for any confusion. I have been testing a try / catch / finally block and purposely raising exceptions and I've noticed that if an exception of "Length of the data to decrypt is invalid." is raised with the CryptoStream object, later this exception will get raised a second time and thrown to the caller when trying to close the stream...
0
9901
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
1
10756
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10371
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9513
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7914
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7081
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
4560
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4159
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3186
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.