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
>
--
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.
