Hi Zoffix, You indeed have a point. More abstraction is always the right answer :).
Some generic framework exposing the necessary information is a very elegant solution. WIth two buts: 1. For something as basic and fundamental as simple syntax checking it's preferably -imho- not to ask the user to install a lot of external dependencies and track their releases (are they in sync with the latest Rakudo release?). If a default/model implementation is part of core (let's say JSON or whatever), you can have your cake and eat it too. 2. I suspect that the JSON-only addition was a quick-fix to give tools a simple and stable interface to errors today. A more elegant solution may take a lot of time? Regards, C. On Fri, Aug 19, 2016 at 2:37 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Thu Aug 18 06:08:06 2016, nxadm wrote: > > As jnthn suggested on irc, maybe an additional JSON error output would > > be great solution for this. This would make error parsing for external > > tooling very easy and stable. > > I rather not add anything specific like that and dream bigger (or smaller, > depending on how you look at it). It should be possible to expose to > module-space the point where all of our Exception objects > currently get flattened into the text the user sees on the screen. > > So then I could write a module Exceptions::JSON that will convert received > Exception objects to JSON and have all of the exceptions dumped as JSON. Or > write Exceptions::Rollbar and have the exceptions be shipped off to > rollbar.com. Or write Exceptions::Rust and output Rust-like exceptions > with expressive pointers to code. Or write Exceptions::Russian and have all > of the errors be translated to Russian language. > > There are far many more desired options for exceptions output. We should > make it possible for module-space to implement all of those options rather > than add a specific one in core. >
