• David (10/10) Oct 20 2012 class BraLaException : Exception {
• Jacob Carlborg (5/15) Oct 20 2012 Perhaps this function can help:
• David (2/6) Oct 21 2012 Unfortunatly not, it expects a function which returns TraceInfo, but I
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (26/36) Oct 21 2012 The backtrace is not printed if the exception is caught:
• David (6/10) Oct 21 2012 I just want to add color to my exceptions and the easiest way is to
• David (5/16) Oct 21 2012 Well, it can be used to way more than only coloring the exception, you
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (13/31) Oct 21 2012 I don't see that: toString() does get used when the exception object

David <d dav1d.de> writes:

class BraLaException : Exception {
     this(string s, string f=__FILE__, size_t l=__LINE__) {
         super(s, f, l);
     }

     override string toString() {
         return "bar";
     }
}


when throwing this exception, I still get the stacktrace and not "bar", 
is it possible to change that behaviour?

Jacob Carlborg <doob me.com> writes:

On 2012-10-20 18:42, David wrote:
 class BraLaException : Exception {
      this(string s, string f=__FILE__, size_t l=__LINE__) {
          super(s, f, l);
      }

      override string toString() {
          return "bar";
      }
 }


 when throwing this exception, I still get the stacktrace and not "bar",
 is it possible to change that behaviour?

Perhaps this function can help:

http://dlang.org/phobos/core_runtime.html#traceHandler

-- 
/Jacob Carlborg

David <d dav1d.de> writes:

 when throwing this exception, I still get the stacktrace and not "bar",
 is it possible to change that behaviour?

 Perhaps this function can help:

 http://dlang.org/phobos/core_runtime.html#traceHandler

Unfortunatly not, it expects a function which returns TraceInfo, but I 
simply wanna modify the resulting string (add escape sequences).

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 10/20/2012 09:42 AM, David wrote:
 class BraLaException : Exception {
 this(string s, string f=__FILE__, size_t l=__LINE__) {
 super(s, f, l);
 }

 override string toString() {
 return "bar";
 }
 }


 when throwing this exception, I still get the stacktrace and not "bar",
 is it possible to change that behaviour?

The backtrace is not printed if the exception is caught:

class MyException : Exception
{
     string s;

     this(string s, string f=__FILE__, size_t l=__LINE__) {
         super("bar", f, l);
         this.s = s;
     }

     override string toString() const
     {
         return s;
     }
}

void main()
{
     try {
         throw new MyException("bar");

     } catch (Exception e) {
         assert(e.toString() == "bar");
     }
}

This behavior makes sense to me because printing the backtrace should 
concern the application, not the exception itself. If the application 
does not want the backtrace printed, it can handle all of the exceptions.

Ali

David <d dav1d.de> writes:

 This behavior makes sense to me because printing the backtrace should
 concern the application, not the exception itself. If the application
 does not want the backtrace printed, it can handle all of the exceptions.

 Ali

I just want to add color to my exceptions and the easiest way is to 
override toString, that is not possible since, the printing-code in 
druntime doesn't call exception.toString, but reimplements it's default 
behaviour.

I "fixed" it:
https://github.com/D-Programming-Language/druntime/pull/331

David <d dav1d.de> writes:

Am 21.10.2012 22:46, schrieb David:>  > This behavior makes sense to me 
because printing the backtrace should
  > concern the application, not the exception itself. If the application
  > does not want the backtrace printed, it can handle all of the
 exceptions.
  >
  > Ali

 I just want to add color to my exceptions and the easiest way is to
 override toString, that is not possible since, the printing-code in
 druntime doesn't call exception.toString, but reimplements it's default
 behaviour.

 I "fixed" it:
 https://github.com/D-Programming-Language/druntime/pull/331

Well, it can be used to way more than only coloring the exception, you 
can also provide additional information etc. and I think it makes more 
sense, why is there a toString implemented if it isn't used.

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 10/21/2012 01:51 PM, David wrote:
 Am 21.10.2012 22:46, schrieb David:> > This behavior makes sense to me
 because printing the backtrace should
  > > concern the application, not the exception itself. If the application
  > > does not want the backtrace printed, it can handle all of the
  > exceptions.
  > >
  > > Ali
  >
  > I just want to add color to my exceptions and the easiest way is to
  > override toString, that is not possible since, the printing-code in
  > druntime doesn't call exception.toString, but reimplements it's default
  > behaviour.
  >
  > I "fixed" it:
  > https://github.com/D-Programming-Language/druntime/pull/331

 Well, it can be used to way more than only coloring the exception, you
 can also provide additional information etc. and I think it makes more
 sense, why is there a toString implemented if it isn't used.

I don't see that: toString() does get used when the exception object 
appears in a string context. That part works.

What you are asking is why not the runtime calls only toString() of the 
object. The backtrace information is helpful as well, so a special 
exception type should not take away that information from the whole 
application. What does the little exception know about the application 
that it decides that the backtrace not be produced? I think the 
exception type is the wrong place to make that decision.

If it is important for the application that the backtrace is not 
printed, it can simply catch all exceptions in main. Backtrace is 
printed only for unhandled exceptions.

Ali