That's not necessarily useful to someone reading it. It gives you the 'where' but not the 'why'. That said I think the why should be included in the 'term' data and that data well documented, so that the coder can print out a useful error that is valuable in his context. I guess we should just concentrate on making sure that exceptions carry sufficient information.
Though the suggestion of having a function that takes a stack trace and returns a string might be pretty useful if it doesn't already exist. On Sat, Mar 26, 2011 at 6:25 PM, Martin Logan <[email protected]> wrote: > 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 <[email protected]> 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 <[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 >> > > > > -- > 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.
