www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - override toString of Exception

reply 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?
Oct 20 2012
next sibling parent reply 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
Oct 20 2012
parent 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).
Oct 21 2012
prev sibling parent reply =?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
Oct 21 2012
parent reply 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
Oct 21 2012
parent reply 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.
Oct 21 2012
parent =?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
Oct 21 2012