View mode: basic / threaded / horizontal-split · Log in · Help
August 24, 2005
Info for uncaught exceptions
If I say:
# assert(something);

and my program fails, I get a filename and line number:
Error: AssertError Failure mymodule(54)

But if I throw an exception:
# throw new Foo();

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
August 24, 2005
Re: Info for uncaught exceptions
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
August 24, 2005
Re: Info for uncaught exceptions
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:

# assert(bool expression, char[] message);

ElfQT
August 24, 2005
Re: Info for uncaught exceptions
> 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
August 25, 2005
Re: Info for uncaught exceptions
On Wed, 24 Aug 2005 14:29:42 +0200, "Uwe Salomon" <post@uwesalomon.de>
wrote:
>> 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

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.

-Chuck
August 25, 2005
Re: Info for uncaught exceptions
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.
>
>-Chuck

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!

-Chuck
August 25, 2005
Re: Info for uncaught exceptions
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
August 25, 2005
Re: Info for uncaught exceptions
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:
>
>> 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.

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?

-Chuck
Top | Discussion index | About this forum | D home