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 <[email protected]> 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 <[email protected]> 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 [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> 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
>
--
You received this message because you are subscribed to the Google Groups
"erlware-dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/erlware-dev?hl=en.
