Wow, it feels like it's 2000. Erlang stepping on up! On Fri, Mar 25, 2011 at 5:14 PM, Martin Logan <[email protected]>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 <[email protected]> > 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 <[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 > >> > > > > > > -- > 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. > > -- 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.
