The pretty print error printer can just be made to take a stacktrace
instead of some Erlware defined exception.
On Sat, Mar 26, 2011 at 6:24 PM, Martin Logan <martinjlo...@gmail.com> wrote:
> Well, if stack traces now give line numbers than any exception can be
> caught and then print_stacktrace can be ran and line numbers and
> filenames will be there for the user to format in whatever way they
> want.
>
> On Fri, Mar 25, 2011 at 4:22 PM, Eric Merritt <ericbmerr...@gmail.com> wrote:
>> The line number can go away thats true. However, this doesn't actually
>> remove the need for what I am talking about here. This is about
>> getting nice user readable strings. Hmmm, but maybe its more important
>> to give more complete error information and letting the catcher make
>> the strings. In any case, as awesome as this is (and it is damn
>> awesome) it doesn't actually have much impact on this discussion.
>>
>> On Fri, Mar 25, 2011 at 4:14 PM, Martin Logan <martinjlo...@gmail.com> wrote:
>>> Not required anymore. Have you guys seen the latest twitter stuff from
>>> Erlang factory. The Erlang/OTP team is adding file and line number as
>>> compile time info to the AST. Sasl dumps will have the info!!!!!!
>>>
>>> On Fri, Mar 25, 2011 at 3:57 PM, Eric Merritt <ericbmerr...@gmail.com>
>>> wrote:
>>>> I am fine with {Module, Line, Term}, It matches the existing thing better.
>>>>
>>>> As for function, if you want that you always have access to the stack
>>>> trace. So i don't thing there is really a need to go to that depth.
>>>> The module is mainly there so you can do the whole Module:format_error
>>>> thing.
>>>>
>>>> Why make the exception a record?
>>>>
>>>> On Mon, Mar 21, 2011 at 10:50 AM, Martin Logan <martinjlo...@gmail.com>
>>>> wrote:
>>>>> I think for errors it could be a bit much. If you were to use such a
>>>>> thing for errors then the tagging atom should be unique, not just
>>>>> error, to distinguish it from errors that don't use that format. For
>>>>> exceptions however, I agree, it is not overkil. I think we should go
>>>>> {Module, Line, Term} however as the ordering makes more sense to me.
>>>>> We could also think about optionally adding in Function (the function
>>>>> that generated the exception) in certain cases, perhaps optional for
>>>>> efficiencies sake, but that may just be too complex. You don't
>>>>> actually gain anything by putting it in first position because it is a
>>>>> tuple which leads me to the next change I would make. I would make the
>>>>> exception a record.
>>>>>
>>>>> On Mon, Mar 21, 2011 at 10:24 AM, Eric Merritt <ericbmerr...@gmail.com>
>>>>> wrote:
>>>>>> Guys,
>>>>>>
>>>>>> I propose that we adopt the stdlib approach to errors printing with a
>>>>>> couple of changes. Right now it is very common for things in kernel
>>>>>> and stdlib to throw exceptions lie.
>>>>>>
>>>>>> {error, {Line, Mod, Term}}
>>>>>>
>>>>>> and then provide a function called format_error in the module called
>>>>>> named by 'Mod' to convert that into a string. I think we should do the
>>>>>> same but with a couple of differences in the organization. I would
>>>>>> like the reason to be more accessible at runtime so, they can be
>>>>>> matched on. The printing of an error message is secondary to
>>>>>> understand why something is being through. Also we can drop part of
>>>>>> this, in general we have the policy to throw exceptions instead of
>>>>>> returning errors. In those cases, the 'error' is not needed its
>>>>>> already a thrown exception.
>>>>>>
>>>>>> throw({pe, Reason::term(), {Mod::module(), Line::integer()}})
>>>>>>
>>>>>> In those few cases, where we explicitly return errors we may do the
>>>>>> following
>>>>>>
>>>>>> {error, {pe, Reason::term(), {Mod::module(), Line::integer()}}
>>>>>>
>>>>>> In both these cases the pe indicates that an exception is printable
>>>>>> using the method described above.
>>>>>>
>>>>>> I would like some consistent means of getting user readable exceptions
>>>>>> from the things that throw them. What do you guys think? Overkill?
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "erlware-dev" group.
>>>>>> To post to this group, send email to erlware-dev@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to
>>>>>> erlware-dev+unsubscr...@googlegroups.com.
>>>>>> For more options, visit this group at
>>>>>> http://groups.google.com/group/erlware-dev?hl=en.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Logan
>>>>> Erlang & OTP in Action (Manning) http://manning.com/logan
>>>>> http://twitter.com/martinjlogan
>>>>> http://erlware.org
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Logan
>>> Erlang & OTP in Action (Manning) http://manning.com/logan
>>> http://twitter.com/martinjlogan
>>> http://erlware.org
>>>
>>
>
>
>
> --
> Martin Logan
> Erlang & OTP in Action (Manning) http://manning.com/logan
> http://twitter.com/martinjlogan
> http://erlware.org
>
--
Martin Logan
Erlang & OTP in Action (Manning) http://manning.com/logan
http://twitter.com/martinjlogan
http://erlware.org
--
You received this message because you are subscribed to the Google Groups
"erlware-dev" group.
To post to this group, send email to erlware-dev@googlegroups.com.
To unsubscribe from this group, send email to
erlware-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/erlware-dev?hl=en.
