custom exception type

vano ivan.melnychuk+news at
Fri Oct 22 10:00:33 PDT 2010

Although it is somewhat annoying that there is no default value for the 
msg parameter in the first constructor, it is pretty easy to use the 
mixin templates to overcome the issue:

public mixin template ExceptionCtorMixin() {
     this(string msg = null, Throwable next = null) { super(msg, next); }
     this(string msg, string file, size_t line, Throwable next = null) {
         super(msg, file, line, next);

class MyException : Exception { mixin ExceptionCtorMixin; }

On 22.10.2010 13:00, 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.
> 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?
> 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);"?
> Denis
> (*) This is exactly the programming pattern somewhere explained in D docs: throw an exception instead of returning a fake value used as failure flag.
> -- -- -- -- -- -- --
> vit esse estrany ☣

More information about the Digitalmars-d-learn mailing list