digitalmars.D - Info for uncaught exceptions
- Chuck Esterbrook (17/17) Aug 24 2005 If I say:
-
Manfred Nowak
(9/14)
Aug 24 2005
Chuck Esterbrook
- ElfQT (6/6) Aug 24 2005 I agree, you better derive from a base error class.
- Uwe Salomon (49/54) Aug 24 2005 What he wants to say in his matchless amiability is the following:
- Chuck Esterbrook (27/81) Aug 24 2005 I was throwing my own ToBeDoneException() which was in fact derived
- Chuck Esterbrook (9/27) Aug 24 2005 On Wed, 24 Aug 2005 20:36:40 -0700, Chuck Esterbrook
- Derek Parnell (9/16) Aug 24 2005 Sounds reasonable, but be warned ... there is no indication that Walter
- Chuck Esterbrook (9/20) Aug 25 2005 Yeah, I agree. But I figure it's one of the more intelligent ways to
If I say: and my program fails, I get a filename and line number: Error: AssertError Failure mymodule(54) But if I throw an exception: I just get: Error: Walter, would it be possible for you to enhance the throw statement to work the filename and line number into the exception, as with the assert statement? And to include the class name of the exception in the output? It would be a huge bonus for speed-of-development to see this: Error: Foo Exception at mymodule(54): <message, if any> instead of this: Error: -Chuck
Aug 24 2005
Chuck Esterbrook <Chuck.Esterbrook gmail.antispam.com> wrote in news:8ddog1pr6po9r4mif530vq394op21f1tnt 4ax.com [...]It would be a huge bonus for speed-of-development to see this: Error: Foo Exception at mymodule(54): <message, if any> instead of this: Error:Why dont you derive your `Foo' from `Error' or `Exception' and supply the information you need? How should the compiler know what text you possibly need? Why should every class incorporate a link to an automatically generated exception handling, when only your speed of development is graded down, without that? -manfred
Aug 24 2005
"ElfQT" <dethjunk yahoo.com> I agree, you better derive from a base error class. But also, compiler should warn if trying to throw a different class. (Is there any meaning in throwing a not-error class?) And assert with an optional message would be better than without: ElfQT
Aug 24 2005
Why dont you derive your `Foo' from `Error' or `Exception' and supply the information you need? How should the compiler know what text you possibly need? Why should every class incorporate a link to an automatically generated exception handling, when only your speed of development is graded down, without that?What he wants to say in his matchless amiability is the following: class FooException : Exception { this(char[] msg) // Possibly more parameters. { super(msg); } } // and then, in the code: throw new FooException("Username unknown."); This way you will get the message "Error: Username unknown.", and normally it should be no problem even in large projects to remember where you threw this error message. If you really need the file/line info (i never did), you can write something like this: class FooException : Exception { char[] m_file; size_t m_line; this(char[] msg, char[] file = null, size_t line = 0) { super(msg); m_file = file; m_line = line; } char[] toString() { if (m_line == 0) { if (m_file is null) return super.toString; else return m_file ~ ": " ~ super.toString; } assert(m_file !is null); return m_file ~ ":" ~ std.string.toString(m_line) ~ ": " ~ super.toString; } } // and then, in the code: throw new FooException("Username unknown.", __FILE__, __LINE__); This is not the most beautiful way, but it is not too ugly, too. Anyways, you should pass a good exception text to *every* exception, IMHO. I would not use a program twice that aborts with "Error." as the explanation. Ciao uwe
Aug 24 2005
On Wed, 24 Aug 2005 14:29:42 +0200, "Uwe Salomon" <post uwesalomon.de> wrote:I was throwing my own ToBeDoneException() which was in fact derived from Exception. And yeah I could spell out the __FILE__, __LINE__ and method name every time. But after awhile that seems a bit silly since the compiler could spell it out for me. The compiler spells out template instantiations and mixins. It spells out the file and line number for "assert". Is it desireable that it not spell it out for "throw"? What's the advantage? Branching off on this, I find D's combination of high level vs. low level behavior strange: - a[i] throws an exception for out-of-bounds, but obj.foo does not throw an exception for obj-is-null. - assert() comes with filename and line number, but thrown exceptions do not - D supports C's += -= etc., but not if it's a property - array.sort will invoke the user-defined opCmp() between objects, but won't take a comparison function/delegate as a parameter - unit tests are highly encouraged, but don't run by default I can't tell if these are things Walter just hasn't done yet, or if he feels that this is how things should be done. And yeah, I know I can "get by with" and "work around" each situation, but I agree with the D overview that "Not being part of the core language has ... suboptimal consequences." I think D would be that much of a better language with the above improvements. -ChuckWhy dont you derive your `Foo' from `Error' or `Exception' and supply the information you need? How should the compiler know what text you possibly need? Why should every class incorporate a link to an automatically generated exception handling, when only your speed of development is graded down, without that?What he wants to say in his matchless amiability is the following: class FooException : Exception { this(char[] msg) // Possibly more parameters. { super(msg); } } // and then, in the code: throw new FooException("Username unknown."); This way you will get the message "Error: Username unknown.", and normally it should be no problem even in large projects to remember where you threw this error message. If you really need the file/line info (i never did), you can write something like this: class FooException : Exception { char[] m_file; size_t m_line; this(char[] msg, char[] file = null, size_t line = 0) { super(msg); m_file = file; m_line = line; } char[] toString() { if (m_line == 0) { if (m_file is null) return super.toString; else return m_file ~ ": " ~ super.toString; } assert(m_file !is null); return m_file ~ ":" ~ std.string.toString(m_line) ~ ": " ~ super.toString; } } // and then, in the code: throw new FooException("Username unknown.", __FILE__, __LINE__); This is not the most beautiful way, but it is not too ugly, too. Anyways, you should pass a good exception text to *every* exception, IMHO. I would not use a program twice that aborts with "Error." as the explanation. Ciao uwe
Aug 24 2005
On Wed, 24 Aug 2005 20:36:40 -0700, Chuck Esterbrook <Chuck.Esterbrook gmail.antispam.com> wrote: [snip]Branching off on this, I find D's combination of high level vs. low level behavior strange: - a[i] throws an exception for out-of-bounds, but obj.foo does not throw an exception for obj-is-null. - assert() comes with filename and line number, but thrown exceptions do not - D supports C's += -= etc., but not if it's a property - array.sort will invoke the user-defined opCmp() between objects, but won't take a comparison function/delegate as a parameter - unit tests are highly encouraged, but don't run by default I can't tell if these are things Walter just hasn't done yet, or if he feels that this is how things should be done. And yeah, I know I can "get by with" and "work around" each situation, but I agree with the D overview that "Not being part of the core language has ... suboptimal consequences." I think D would be that much of a better language with the above improvements. -ChuckI was rummaging around the news archives as I often do just to pick up more knowledge, and found this really neat site: http://all-technology.com/eigenpolls/dwishlist/ So I guess this is where I should dump my "wishes" and let them duke it out with the others! -Chuck
Aug 24 2005
On Wed, 24 Aug 2005 21:20:19 -0700, Chuck Esterbrook wrote:I was rummaging around the news archives as I often do just to pick up more knowledge, and found this really neat site: http://all-technology.com/eigenpolls/dwishlist/ So I guess this is where I should dump my "wishes" and let them duke it out with the others!Sounds reasonable, but be warned ... there is no indication that Walter ever uses the information at that site. Meaning that he may look at it, but there is no evidence that he does. -- Derek (skype: derek.j.parnell) Melbourne, Australia 25/08/2005 3:49:23 PM
Aug 24 2005
On Thu, 25 Aug 2005 15:51:13 +1000, Derek Parnell <derek psych.ward> wrote:On Wed, 24 Aug 2005 21:20:19 -0700, Chuck Esterbrook wrote:Yeah, I agree. But I figure it's one of the more intelligent ways to express what changes we'd like to see in D. It's interesting to see what gets the most votes and hopefully that piques his interest. Of course, we could ask: Hey, Walter does that wishlist page, with its vote counting, interest you at all? -ChuckI was rummaging around the news archives as I often do just to pick up more knowledge, and found this really neat site: http://all-technology.com/eigenpolls/dwishlist/ So I guess this is where I should dump my "wishes" and let them duke it out with the others!Sounds reasonable, but be warned ... there is no indication that Walter ever uses the information at that site. Meaning that he may look at it, but there is no evidence that he does.
Aug 25 2005