digitalmars.D - Question/suggestion about exceptions
- Graham St Jack (15/15) Oct 23 2006 Is there a way to automatically keep track of what exceptions may be
- BCS (16/34) Oct 23 2006 I would think You could be able to get most of that from a code analysis...
- Graham St Jack (4/45) Oct 23 2006 I have thought about writing an analysis tool, but it is all a bit
- Ary Manzana (5/23) Oct 24 2006 I totally support this idea. Is it hard to implement in the compiler? Of...
- Sean Kelly (5/31) Oct 24 2006 It won't work with extern (C) functions, since the exception list would
- Graham St Jack (16/50) Oct 24 2006 I can't be too hard to implement in the compiler because Java does it
- Sean Kelly (6/10) Oct 24 2006 extern (C) is just a calling convention. extern (C) functions can be
Is there a way to automatically keep track of what exceptions may be thrown by a function or method? Ideally, what I am looking for is something like Java's "throws" keyword, but I would be happy with almost anything. It is way too hard to develop reliable code of any size that uses exceptions extensively, because as things change, you lose track of what exceptions are thrown from where. Some sort of compiler support would make this a lot easier. What I had in mind was an optional compiler warning and a new "throws" keyword. The compiler would (optionally) issue a warning if a function or method can throw an exception that it hasn't declared that it "throws". With this assistance, it becomes is easy to keep track of what can be thrown from where. Making it a warning and optional stops it from breaking existing code, and makes quick code hacks easy to write still. Thoughts?
Oct 23 2006
Graham St Jack wrote:Is there a way to automatically keep track of what exceptions may be thrown by a function or method? Ideally, what I am looking for is something like Java's "throws" keyword, but I would be happy with almost anything. It is way too hard to develop reliable code of any size that uses exceptions extensively, because as things change, you lose track of what exceptions are thrown from where. Some sort of compiler support would make this a lot easier. What I had in mind was an optional compiler warning and a new "throws" keyword. The compiler would (optionally) issue a warning if a function or method can throw an exception that it hasn't declared that it "throws". With this assistance, it becomes is easy to keep track of what can be thrown from where. Making it a warning and optional stops it from breaking existing code, and makes quick code hacks easy to write still. Thoughts?I would think You could be able to get most of that from a code analysis tool that dumps the type of all throw statements and a function call tree. A a "linker" with a little DDoc like markup and you'd have quite a tool. OTOH this: int foo(int function() fn) { return fn(); } could throw anything, as could this: int foo(Error err) { throw err; } so some odd cases might not be so clean.
Oct 23 2006
I have thought about writing an analysis tool, but it is all a bit tricky when you have overloaded operators and methods, and try/catch blocks. This is something the compiler has to do. BCS wrote:Graham St Jack wrote:Is there a way to automatically keep track of what exceptions may be thrown by a function or method? Ideally, what I am looking for is something like Java's "throws" keyword, but I would be happy with almost anything. It is way too hard to develop reliable code of any size that uses exceptions extensively, because as things change, you lose track of what exceptions are thrown from where. Some sort of compiler support would make this a lot easier. What I had in mind was an optional compiler warning and a new "throws" keyword. The compiler would (optionally) issue a warning if a function or method can throw an exception that it hasn't declared that it "throws". With this assistance, it becomes is easy to keep track of what can be thrown from where. Making it a warning and optional stops it from breaking existing code, and makes quick code hacks easy to write still. Thoughts?I would think You could be able to get most of that from a code analysis tool that dumps the type of all throw statements and a function call tree. A a "linker" with a little DDoc like markup and you'd have quite a tool. OTOH this: int foo(int function() fn) { return fn(); } could throw anything, as could this: int foo(Error err) { throw err; } so some odd cases might not be so clean.
Oct 23 2006
Graham St Jack wrote:Is there a way to automatically keep track of what exceptions may be thrown by a function or method? Ideally, what I am looking for is something like Java's "throws" keyword, but I would be happy with almost anything. It is way too hard to develop reliable code of any size that uses exceptions extensively, because as things change, you lose track of what exceptions are thrown from where. Some sort of compiler support would make this a lot easier. What I had in mind was an optional compiler warning and a new "throws" keyword. The compiler would (optionally) issue a warning if a function or method can throw an exception that it hasn't declared that it "throws". With this assistance, it becomes is easy to keep track of what can be thrown from where. Making it a warning and optional stops it from breaking existing code, and makes quick code hacks easy to write still. Thoughts?I totally support this idea. Is it hard to implement in the compiler? Of course, there should also be a hierarchy of exceptions, just like Java: RuntimeException dosen't signal an error when not try-catching it. Thoughts? :-)
Oct 24 2006
Ary Manzana wrote:Graham St Jack wrote:It won't work with extern (C) functions, since the exception list would probably be a part of the mangled function name. This is why 'throws' goes basically unused in C++, even though the feature is present. SeanIs there a way to automatically keep track of what exceptions may be thrown by a function or method? Ideally, what I am looking for is something like Java's "throws" keyword, but I would be happy with almost anything. It is way too hard to develop reliable code of any size that uses exceptions extensively, because as things change, you lose track of what exceptions are thrown from where. Some sort of compiler support would make this a lot easier. What I had in mind was an optional compiler warning and a new "throws" keyword. The compiler would (optionally) issue a warning if a function or method can throw an exception that it hasn't declared that it "throws". With this assistance, it becomes is easy to keep track of what can be thrown from where. Making it a warning and optional stops it from breaking existing code, and makes quick code hacks easy to write still. Thoughts?I totally support this idea. Is it hard to implement in the compiler? Of course, there should also be a hierarchy of exceptions, just like Java: RuntimeException dosen't signal an error when not try-catching it. Thoughts? :-)
Oct 24 2006
Sean Kelly wrote:Ary Manzana wrote:I can't be too hard to implement in the compiler because Java does it already. However, a lot of people find the discipline of having to think about exception handling too disruptive to the creative process (I have mixed feelings too). This is why I suggested adding the feature as an optional warning. That way you can crank out code without difficulty, then go back later and think about exception handling. It doesn't need to work with extern (C) functions because they don't throw exceptions, and even if they did, you could wrap the problematic ones in D code so that exceptions would be tracked from there. I agree that an exception hierarchy is a good thing, and I like the Java approach of the compiler errors only being generated for exceptions rather than "errors" like out-of-memory. Something like that could be done here too because D uses an exception hierarchy too - maybe by telling the compiler via a switch what exception base class (and all specializations) you want to be warned about.Graham St Jack wrote:It won't work with extern (C) functions, since the exception list would probably be a part of the mangled function name. This is why 'throws' goes basically unused in C++, even though the feature is present. SeanIs there a way to automatically keep track of what exceptions may be thrown by a function or method? Ideally, what I am looking for is something like Java's "throws" keyword, but I would be happy with almost anything. It is way too hard to develop reliable code of any size that uses exceptions extensively, because as things change, you lose track of what exceptions are thrown from where. Some sort of compiler support would make this a lot easier. What I had in mind was an optional compiler warning and a new "throws" keyword. The compiler would (optionally) issue a warning if a function or method can throw an exception that it hasn't declared that it "throws". With this assistance, it becomes is easy to keep track of what can be thrown from where. Making it a warning and optional stops it from breaking existing code, and makes quick code hacks easy to write still. Thoughts?I totally support this idea. Is it hard to implement in the compiler? Of course, there should also be a hierarchy of exceptions, just like Java: RuntimeException dosen't signal an error when not try-catching it. Thoughts? :-)
Oct 24 2006
Graham St Jack wrote:It doesn't need to work with extern (C) functions because they don't throw exceptions, and even if they did, you could wrap the problematic ones in D code so that exceptions would be tracked from there.extern (C) is just a calling convention. extern (C) functions can be implemented in D code and can throw exceptions, as far as I know. I do feel that exception contracts are potentially useful however, even if I've never really warmed up to a particular implementation. Sean
Oct 24 2006