Can someone explain this...
-
private void ReadDaqThreadProc()
{
dThreadCallback tcb = new dThreadCallback(ReadDaq);
while (flags.daqEnabled)
{
try
{
this.Invoke(tcb, new Object[] { }); }
catch (Exception e)
{
}
Thread.Sleep(50);
}
}This snippet is part of a multithreaded app. "tcb" is a delegate, ReadDaq is a function in the MainForm code, and ReadDaqThreadProc is in its own thread. I know what the code does but I dont know how. I'd like to understand how this works. The line in question is the invoke line. Is 'new Object[] {}' an argument list for ReadDaq?
-
private void ReadDaqThreadProc()
{
dThreadCallback tcb = new dThreadCallback(ReadDaq);
while (flags.daqEnabled)
{
try
{
this.Invoke(tcb, new Object[] { }); }
catch (Exception e)
{
}
Thread.Sleep(50);
}
}This snippet is part of a multithreaded app. "tcb" is a delegate, ReadDaq is a function in the MainForm code, and ReadDaqThreadProc is in its own thread. I know what the code does but I dont know how. I'd like to understand how this works. The line in question is the invoke line. Is 'new Object[] {}' an argument list for ReadDaq?
Yes, it's passing an empty object array (the default container for invoke-params) and calling "tcb", the
ReadDaqmethod - a method without parameters. And it seems to swallow any exceptions, which isn't such a great thing.Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
Yes, it's passing an empty object array (the default container for invoke-params) and calling "tcb", the
ReadDaqmethod - a method without parameters. And it seems to swallow any exceptions, which isn't such a great thing.Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
It should be in a try block?
-
It should be in a try block?
Member 8461599 wrote:
It should be in a try block?
Why? Which exceptions does the
Invokemethod throw? It's only there to ensure that any exceptions from the implementation of the method do not kill the application; and those exceptions should be handled there - locally; not here. Also, it's wise to "log" all exceptions, as a "swallow all and be silent" is a known point of failure. Sometimes an exception is thrown away that you did not expect, causing weird program-behaviour.Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
Member 8461599 wrote:
It should be in a try block?
Why? Which exceptions does the
Invokemethod throw? It's only there to ensure that any exceptions from the implementation of the method do not kill the application; and those exceptions should be handled there - locally; not here. Also, it's wise to "log" all exceptions, as a "swallow all and be silent" is a known point of failure. Sometimes an exception is thrown away that you did not expect, causing weird program-behaviour.Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
It should be in a try block?
The exceptions which could arise in the ReadDaq function will arise in a different thread - the thread of the GUI. You are not able to catch them here, hence you can omit the try-catch-block here. But ReadDaq ought to have its own try-catch.
-
private void ReadDaqThreadProc()
{
dThreadCallback tcb = new dThreadCallback(ReadDaq);
while (flags.daqEnabled)
{
try
{
this.Invoke(tcb, new Object[] { }); }
catch (Exception e)
{
}
Thread.Sleep(50);
}
}This snippet is part of a multithreaded app. "tcb" is a delegate, ReadDaq is a function in the MainForm code, and ReadDaqThreadProc is in its own thread. I know what the code does but I dont know how. I'd like to understand how this works. The line in question is the invoke line. Is 'new Object[] {}' an argument list for ReadDaq?
not 100% sure, but you could pass null instead of new Object[]{}. The signature of the Invoke method requires an object array. This is actually used to box/unbox parameters for the threading function. If null is allowed (I think so) this is for me preferable, because it indicates we're passing it to fulfill the method requirement. passing a new Object[]{} not only initializes memory, but also might indicate we "forgot" to do something. Hope this helps.
V.
(MQOTD Rules ) -
If you'll forgive my ignorance... I guess I dont know what you mean by "swallow any exceptions, which isn't such a great thing". My knowledge of C# isnt very deep, as you can see.
This code:
try
{
...
}
catch (Exception e)
{
}is called "swallowing an exception", because whatever error occurs in the try block will be caught by the catch block and discarded without any attempt to handle it, log it, or in any other way acknowledge that there is a problem that should be fixed, or at least investigated. This is considered a poor programming practice, as it just masks problems that may become serious later. There can (occasionally) be a good reasons for ignoring specific exceptions, but these should be restricted to specific exception classes (such as ArgumentNullException, or FileLoadException) rather than a blanket "Exception" and commented thoroughly.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
The exceptions which could arise in the ReadDaq function will arise in a different thread - the thread of the GUI. You are not able to catch them here, hence you can omit the try-catch-block here. But ReadDaq ought to have its own try-catch.
Bernhard Hiller wrote:
You are not able to catch them here,
No, not quite true (at all). The Invoke mechanism catches an unhandled exception within the target method and rethrows it in the calling thread. In doing this the stack trace containing the site of the original exception is lost. Whether or not something bad happens when the exception is rethrown depends on the caller. For example I've noticed that the thread used by a System.Timers.Timer to call the Elapsed event handler carries on obliviously with no hint of discomfort! See the remarks section in Control.Invoke[^] Alan.
-
This code:
try
{
...
}
catch (Exception e)
{
}is called "swallowing an exception", because whatever error occurs in the try block will be caught by the catch block and discarded without any attempt to handle it, log it, or in any other way acknowledge that there is a problem that should be fixed, or at least investigated. This is considered a poor programming practice, as it just masks problems that may become serious later. There can (occasionally) be a good reasons for ignoring specific exceptions, but these should be restricted to specific exception classes (such as ArgumentNullException, or FileLoadException) rather than a blanket "Exception" and commented thoroughly.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
Ahh... Gotcha. There actually is code there. I took it out when I posted it here.
-
Ahh... Gotcha. There actually is code there. I took it out when I posted it here.
:thumbsup:
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
