toString should be final, it should do exactly what Sean is doing, return
file:line: msg, and I would say a stack trace as well.
msg should be a virtual property, and that's where someone can affect both
toString and the runtime printout.
So essentially, exactly what Andrei said, but s/toStringImpl/msg/
>From Microsoft's Exception class (always good to look at what other languages
>do):
"ToString returns a representation of the current exception that is intended to
be understood by humans. Where the exception contains culture-sensitive
data, the string representation returned by ToString is required to take into
account the current system culture. Although
there are no exact requirements for the format of the returned string,
it should attempt to reflect the value of the object as perceived by
the user.
The default implementation of ToString obtains the name of the class that threw
the current exception, the message, the result of calling ToString on the inner
exception, and the result of calling Environment.StackTrace. If any of these
members is Nothing, its value is not included in the returned string.
If
there is no error message or if it is an empty string (""), then no
error message is returned. The name of the inner exception and the
stack trace are returned only if they are not Nothing.
This method overrides Object.ToString."
-Steve
----- Original Message ----
> From: Andrei Alexandrescu <[email protected]>
> To: Discuss the phobos library for D <[email protected]>
> Sent: Wed, April 7, 2010 2:39:20 PM
> Subject: Re: [phobos] Printing exceptions
>
> This seems to be an instance of the problem NVI is supposed to solve: the
> interface for users should not be the same as the interface for
> customization.
In an NVI approach, toString would be final and there
> would be an overridable toStringImpl that users can tweak. Then toString
> would
> call toStringImpl and decorate it with stack trace info etc.
Anyway,
> since toString is already overridable, I suggest you just add a
> detailedReason()
> function that formats and returns a string including whatever toString()
> returns, then also file and line info and stack trace. If an exception leaves
> main(), print detailedReason(), not toString().
Andrei
On
> 04/07/2010 01:09 PM, Sean Kelly wrote:
> On Apr 7, 2010, at 8:53 AM,
> Robert Clipsham wrote:
>
>> On 07/04/10 16:29, Sean Kelly
> wrote:
>>> The runtime can do one of two things: print exceptions
> according to a standard format and inject the msg field in the proper place
> or
> it can call toString. Which should be done? I prefer the former
> because it makes for a standard presentation and doesn't risk allocating
> memory
> needlessly, but I can see how people might do fancy stuff in toString that
> they
> expect to be used instead. This came up because I'm adding a default stack
> trace handler, and the current behavior prints the stack trace twice, so
> something needs to change.
>>
>> I think the better option
> would be to print them in the standard format, at least by default. You could
> always include several trace handlers to allow the user to effortlessly pick
> the
> handler they want, rather than everyone implementing their own for when they
> want to use toString.
>
> My worry is that someone will do
> something fancy in their toString override and expect it to print if the
> exception escapes main(). The default behavior is basically to print
> "file:line: msg" which sidesteps any custom code in toString completely.
> The current code is actually a bit weird and uses the custom format if the
> file
> string is non-null and calls toString otherwise, but that seems like it's
> even
> less predictable than simply always using a custom or the toString format.
> I also don't see any easy way to provide a default formatter, since ranges
> are
> defined in Phobos and not druntime (ie. you couldn't have
> Exception.outputTo(Range)).
>
> I've personally never liked
> toString, but since it exists it seems like the only reasonable thing to do
> is
> always call it.
> _______________________________________________
>
> phobos mailing list
>
> href="mailto:[email protected]";>[email protected]
>
> http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos
> mailing list
> href="mailto:[email protected]";>[email protected]
> href="http://lists.puremagic.com/mailman/listinfo/phobos"; target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
