custom exception type

[Lars T. Kyllingstad]

On Fri, 22 Oct 2010 13:00:43 +0200, spir wrote:

> Hello,
> 
> Where can one find descriptions of Throwable, Error, & Exception? (I
> mean, how do you even know they exist?) I could finally guess the
> constructor must have a string parameter used for error output.

Well, they should be in the documentation for the 'object' module, but I 
see that they aren't.  Until that is fixed, you can check out the 
source.  Throwable starts at line 1210 here:

  http://www.dsource.org/projects/druntime/browser/trunk/src/object_.d

Exception and Error immediately follow it, but they don't really add 
anything to Throwable.


> Also, is it possible to implicitely reuse the superclass's constructor?
> I had to write:
> 
> class E : Exception {
>     this (string msg) {
>         super(msg) ;
>     }
> }
> 
> E.this performs nothing new. But without it, I get a compiler error:
>     trial.d(7): Error: constructor trial.E.this no match for implicit
>     super() call in constructor
> Isn't the constructor inherited like other attributes?

No.  With the exception of a no-argument constructor, which Throwable 
doesn't have, you have to call it explicitly with super(...).


> Finally, is it possible to customize the error message construction,
> using eg tostring? A big issue is that, currently, an exception's
> message is computed at construction time, even if the exception will
> never be thrown, or more ccommonly never be output -- because it is
> caught by a 'catch' clause. In some cases, constructing the message can
> be costly; some programming schemes may throw huge numbers of
> exceptions, all caught (or nearly all). Example: in a parsing library,
> pattern match methods throw an instance of MatchFailure when matching
> fails. When there is a pattern choice, there may be numerous failures
> for each success. MatchFailure is just a clean way of signaling this
> fact (*): each failure exception is caught at a higher level to allow
> trying the alternative patterns. Since error messages can be rather
> complicated, constructing them uselessly would multiply parsing time by
> a rather big factor (in my case, ~ X 30!). I guess tostring is the right
> feature for this: it would return the exception's textual form, ie the
> message. (For information, this is how Python works.) I tried to use it,
> but it seems to be simply ignored. What is the func/method that
> constructs the text of an exception, eg what is implicitely called by
> "writeln(e);"?

That would be toString(), not tostring().

-Lars