www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - custom exception type

reply spir <denis.spir gmail.com> writes:
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 mus=
t have a string parameter used for error output.

Also, is it possible to implicitely reuse the superclass's constructor? I h=
ad 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 comp=
uted at construction time, even if the exception will never be thrown, or m=
ore ccommonly never be output -- because it is caught by a 'catch' clause. =
In some cases, constructing the message can be costly; some programming sch=
emes may throw huge numbers of exceptions, all caught (or nearly all).
Example: in a parsing library, pattern match methods throw an instance of M=
atchFailure 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 rath=
er 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 excepti=
on's textual form, ie the message. (For information, this is how Python wor=
ks.) 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 ca=
lled 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 =E2=98=A3

spir.wikidot.com
Oct 22 2010
next sibling parent Trass3r <un known.com> writes:
 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?


I think if you don't provide a constructor a default one is created:  
this(){}
Then an implicit call to super() is inserted cause there's no explicit one.
But there is no this() without parameters in the Exception class if I'm  
not mistaken. You can look it up in _object.d in the druntime source.
Oct 22 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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
Oct 22 2010
prev sibling parent vano <ivan.melnychuk+news gmail.com> writes:
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 ☣

 spir.wikidot.com
Oct 22 2010