replace definition of error with errorWithStackTrace

[Johan Tibell]

The idea with using dwarf info is that error (and all exception messages)
would always include a stack trace automatically, just like in other
languages.
On Dec 17, 2014 5:49 AM, "Christopher Allen" <cma at bitemyapp.com> wrote:

> I don't think the dwarf information replaces the utility of this proposal,
> this proposal, critically, will help the new users who won't know how to
> use debugging information. It'll also give people useful first-pass
> information for reproducing the error for later, more detailed debugging.
>
> I'd very much like to see this happen if there aren't technical arguments
> against it.
>
> --- Chris Allen
>
>
> On Tue, Dec 16, 2014 at 10:38 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>>
>> if the dwarf information work is landing in 7.10 (as it seems to be),
>> perhaps my proposal is moot. But either way, making error "foo" and friend
>> more informative by default would be a great thing to make sure happens.
>>
>> I think we had a clear majority supporting this proposal, but i think
>> *some* basic dwarf support got merged in today?
>>
>> -Carter
>>
>> On Tue, Dec 2, 2014 at 5:02 AM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>>
>>> Why don't we use the DWARF information instead? It has no runtime
>>> overhead so it can actually be turned on always. It also integrates with
>>> all the standard open source tooling.
>>>
>>> On Tue, Dec 2, 2014 at 10:04 AM, Simon Peyton Jones <
>>> simonpj at microsoft.com> wrote:
>>>
>>>>   +1, as I don't see a downside. However, I don't think this change is
>>>> a sufficient change as long as stack traces are only available for profiled
>>>> builds. I still wish something like rewrite-with-location[1], which even
>>>> addresses explicit stack traces directly[2]. IIRC, last time that feature
>>>> was brought up for discussion, it stalled due to disagreements on the right
>>>> design.
>>>>
>>>> I think we have something of a consensus forming around
>>>> https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations,
>>>> see #9049.   It’s simple, non-invasive, and predicatable.  It does need
>>>> someone to implement it though.   Simon Hengel is thinking about
>>>> implementing it.  (He is the one who also suggested “rewrite with
>>>> location”).
>>>>
>>>>
>>>>
>>>> So I think we are stalled not so much on design but on implementation.
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of
>>>> *Michael Snoyman
>>>> *Sent:* 01 December 2014 05:33
>>>> *To:* Christopher Allen; Mark Wotton
>>>> *Cc:* Haskell Libraries
>>>> *Subject:* Re: replace definition of error with errorWithStackTrace
>>>>
>>>>
>>>>
>>>> +1, as I don't see a downside. However, I don't think this change is a
>>>> sufficient change as long as stack traces are only available for profiled
>>>> builds. I still wish something like rewrite-with-location[1], which even
>>>> addresses explicit stack traces directly[2]. IIRC, last time that feature
>>>> was brought up for discussion, it stalled due to disagreements on the right
>>>> design.
>>>>
>>>>
>>>>
>>>> [1] https://github.com/sol/rewrite-with-location
>>>>
>>>> [2] https://github.com/sol/rewrite-with-location#explicit-call-stacks
>>>>
>>>>
>>>>
>>>> On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen <cma at bitemyapp.com>
>>>> wrote:
>>>>
>>>>  +1 - I would be very happy if this happened.
>>>>
>>>>
>>>>
>>>> On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton <mwotton at gmail.com>
>>>> wrote:
>>>>
>>>>  having just spent a day tracking down a really uninformative error in
>>>> Cabal, I'm all for this.
>>>>
>>>> On Mon Dec 01 2014 at 11:08:35 Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>
>>>> http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorWithStackTrace
>>>>
>>>>
>>>> has been in GHC for for >=1 major version,
>>>>
>>>> and for normal builds, acts just like error, BUT, when an error is
>>>> thrown in a profiled build, it appends a stack trace with some basic source
>>>> location data to the end of the error message!
>>>>
>>>>
>>>>
>>>> I think this change would benefit many!
>>>>
>>>>
>>>>
>>>> My current understanding is that the DWARF based approach to stack
>>>> traces wont make it into  GHC 7.10 , and while this variant would only
>>>> provide extra info in profiling builds (and strictly less than the dwarf
>>>> work), its something that can definitely be done in a single small patch
>>>> that could easily be swapped out for that improved approach once it lands.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> discussion period: 2 weeks unless theres a clear unanimous agreement to
>>>> make the change ASAP, OR if the stack trace error stuff is landing in 7.10
>>>> and I'm misinformed!
>>>>
>>>>
>>>>
>>>> cheers
>>>>
>>>> -Carter
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141217/12bfe7b6/attachment.html>