|
Marc Clifton wrote:
Try
Catch ex As Exception
End Try
Marc Clifton wrote: I did not remove any code. It was a completely empty try-catch block.
Leaving the try...catch block empty was intentional. There exists a form with a textbox in which you can type code to be inserted in the try...catch block at runtime.
|
|
|
|
|
Then it's too bad the optimizer will remove it. 
This space intentionally left blank.
|
|
|
|
|
Today I came across the following code
if (1=1){
doSomeThing();
}
else{
doBestThing();
}
I am waiting for the execution of else part 
|
|
|
|
|
Quantum computing when all is possible at the same time?
|
|
|
|
|
Madhanlal JM wrote: if (1=1){
That does not even compile on any braced language i know of. 
(yeah, i'm just nitpicking)
|
|
|
|
|
well, it will compile for C and C++ at least!
you young spring chicken! :P
|
|
|
|
|
Are you sure it will compile? '1' is not an l-value.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I wont, you can't assign to an rvalue.
UNLESS 1 is actually a macro that expands to something that makes sense on that context, but I don't even know if a macro can be called 1.
|
|
|
|
|
You cannot write a macro beginning with an digit.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I'm digging deep into the past, but I believe that with MS QuickC, it may have allowed the compile. Upon execution, memory offset 1 would be overwritten with 1. Possibly an immediate crash, or more likely, a crash waiting to happen.
I know it'd work with a cast to a pointer. QuickC was rather forgiving at times. Some of those times it was to my regret.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I happened upon an if yesterday that was deactivated with:
if ( <big>false &&</big> ...
Personally, I prefer to build with warnings as errors, but this codebase throws thousands of warnings.
This space intentionally left blank.
|
|
|
|
|
Luckily the Mayans were wrong or perhaps doBestThing() would have executed a couple of years ago.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Madhanlal JM wrote:
if(1=1){
doSomeThing();
}
else{
doBestThing();
}
I am waiting for the execution of else part
if (1=1){
doSomeThing();
Goto l;
}
else{
l: doBestThing();
}
Now the else part will run! Am I Correct? 
|
|
|
|
|
I am not a goto expert(thank God) but i believe you have to define I before the Goto part.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Argonia wrote:
I can see that.. of course you can go to to a label define after, in C, C++, C# at least!
|
|
|
|
|
1 = 1
Or
1 - 1 = 0
Or
0 = 1 - 1
|
|
|
|
|
Better saying
if (1 = l)
{
}
...
As this will throw a compiler error,
|
|
|
|
|
I knew that exceptions in the Load or Shown event of a Form get swallowed on 64bit systems (see e.g. https://connect.microsoft.com/VisualStudio/feedback/details/357311[^]). But this was not such an event.
The autosave procedure of our application receives its start signal from a System.Timers.Timer. The log file entries showed that the Timer_Elapsed handler was called. But strangely, not all of it... But nowhere an exception could be found in the log files, autosave simply did not work.
A newer version of a ThirdParty control fails at a property get when not run in the UI thread - that's where the execution of the Elapsed handler suddenly stopped.
But actually that's nothing new at all, you can read in the MSDN[^]Quote: In the .NET Framework version 2.0 and earlier, the Timer component catches and suppresses all exceptions thrown by event handlers for the Elapsed event. This behavior is subject to change in future releases of the .NET Framework.
Still true with .Net 4. Now I know that too.
|
|
|
|
|
System.Timers.Timer runs in its own Thread. If you don't catch the exceptions in there (e.g. You don't have a try catch around everything in the Elapsed Event) the exception is lost.
|
|
|
|
|
And if it did not swallow the exception, your entire application would go down with a unhandled exception.
I guess the designers decided that it was better to not let the application die due to a simple timed event (that would likely execute again)
|
|
|
|
|
There are two ways to crash your application:
- The exception occurred on the main thread (that is the same as where the main function is called)
- Corrupted State Exceptions that you usually just can't handle (e.g. AccessViolationException, StackOverflowException (if thrown by the OS), etc.) and the application just isn't in a state where it could continue (Yeah, I know, you CAN catch an AccessViolationException, but it's generally not encouraged)
I don't see any reason why an entire application should go boom because one single thread messed something up 
|
|
|
|
|
Nicholas Marty wrote: I don't see any reason why an entire application should go boom because one
single thread messed something up
1) So that you know it did!
Trying to save people from themselves is not generally a worthwhile endeavor.
This space intentionally left blank.
|
|
|
|
|
run this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace ConsoleApplication1 {
class Program {
static void Main(string[] args) {
new Thread(_ => { throw new ArgumentException(); }).Start();
for (int i = 0; i < 1000; i++) {
Console.WriteLine("Wasting time...");
}
Console.ReadKey();
}
}
}
The application crashes with an unhandled exception. ANY unhandled exception on ANY thread crashes the app.
I Learned this from C# 5.0 in a nutshell from john albahari, here's an excerpt:
Quote: AppDomain.CurrentDomain.UnhandledException fires on any unhandled exception on
any thread, but since CLR 2.0, the CLR forces application shutdown after your event
handler completes.
Also, for anyone reading this, I strongly recomend that book.
|
|
|
|
|
As well it should; what's your point?
This space intentionally left blank.
|
|
|
|
|
I was just giving my 2 cents on why that design decision might have been made, without getting into the merit of saying if it's the right way™ or not.
I do defend the crash on this situation, as there's no way to know if the thread ended on a valid state or not.
I interpreted Nicholas Marty's answer as saying that those are the only ways an application might terminate due to an unhandled exception, and felt the necessity to point out that an unhandled exception on any thread would terminate the application, and not just on the main thread, as was implied.
It's also worth noting that if the unhandled exception is on another app domain, you can just handle the AppDomain.CurrentDomain.UnhandledException trashing the offending app domain, then continuing to run normally.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
