-Stephen Johnston
At 07:11 PM 12/8/2003, you wrote:
> Ummm, no. Methods are things that can do things. Being the top-level > method frame in a stack is just one thing you can do with a thread. > Methods should NOT be decorated with "threadentry" or other such > attributes.
> You know you're starting a thread. So put a freakin' try/catch at your > top-level. There's no need to pollute the language with thread-specific > stuff like this. It doesn't add any real value.
To coin a phrase, ummm, no. Relying on programmers to put try-catch blocks in 100% of the time is naive. Just like relying on programmers to always delete ptrs in C++ was naive. Let's face it, humans forget stuff; hence unhandled exceptions and memory leaks - two of the most common problems in software today.
And this is the whole point of my rant - the language is designed for *humans* and humans forget things, so it should *require* exception handling at the root of the call tree. Period. And to this rule (i.e all exceptions MUST be handled by someone) there are NO exceptions, I'm sure you'll agree.
And as for the semantics of the generic method "that can do things" I think it's fair to say the outer method of a thread (that conceptually cannot return to anything because nothing called it) is very different from inner methods insofar as it MUST NEVER throw an exception. Or are you proposing a "special exception handler" for "unhandled" exceptions? THAT is far more offensive than any new keyword! :p
-jade
-----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of Arlie Davis Sent: Tuesday, 9 December 2003 10:03 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] thread exceptions terminate entire app - forcing try-catch usage
Ummm, no. Methods are things that can do things. Being the top-level method frame in a stack is just one thing you can do with a thread. Methods should NOT be decorated with "threadentry" or other such attributes.
Java has things like this, with declared exceptions that are thrown from a thread. Apparently, the CLR team make a conscious decision to omit this "feature". After years of Java programming, I'm glad they did.
You know you're starting a thread. So put a freakin' try/catch at your top-level. There's no need to pollute the language with thread-specific stuff like this. It doesn't add any real value.
Also, by the time an exception has bubbled *that* far up the stack, you've probably got some serious carnage elsewhere. The best you can hope for is to write some diagnostics information somewhere, and either shut down, or re-start whatever the thread was doing. However, that's no substitute for deep exception handling -- you STILL need catch blocks deep in your code, so you can handle exceptions when you have enough context to make sense of them, and enough stack left that you can repair data structures before popping.
-- arlie
-----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Jade Burton Sent: Monday, December 08, 2003 5:15 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] thread exceptions terminate entire app - forcing try-catch usage
> Yes, if I wrote a server and I had a bug in it that resulted in an > unhandled exception, then the absolute last thing I want to do it keep
> running. There would be no means of determining what state the app was
> in, what resources were allocated and locked, what mutexes were > abandoned, etc. It's a bug, and one that should be detected as rapidly
> as possible. Servers should wrap ALL incoming methods in try-catch > handlers.
I agree completely!
However, for a language that has intrinsic structured exception handling even this proposed (terminate on unhandled ex) behaviour does seem sketchy to me.
Perhaps the best cure is prevention: one idea would have been for the C# team to ENFORCE a try-catch block at the root of every thread. (well, at least for the code that can be determined at compile-time.) Note my new hypothetical keyword...
protected threadentry void MyThread() { try { SomeMethod(); } catch (Exception) // if no try-catch, compiler generates error: // "Threads must catch all exceptions." { } }
One thing that always amuses me about C++ programmers (and I am one) is the way they often forget that methods throw exceptions at all. For example in every C++ program there is almost always the possibility of memory overflow exceptions being thrown from all but the most inert code - but how often have you seen try-catch handlers for memory exceptions?? And how many bugs have you fixed in your life in C++ code caused by missing try-catch blocks?
Hopefully with C# there will be a culture change re using try-catch blocks much more often.
-jade
=================================== This list is hosted by DevelopMentor. http://www.develop.com Some .NET courses you may be interested in:
Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls
Guerrilla .NET, 8 Dec 2003, in Los Angeles http://www.develop.com/courses/gdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
=================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in:
Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls
Guerrilla .NET, 8 Dec 2003, in Los Angeles http://www.develop.com/courses/gdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
=================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in:
Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls
Guerrilla .NET, 8 Dec 2003, in Los Angeles http://www.develop.com/courses/gdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
