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 <[email protected]> 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 <[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 >> > -- 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.
