Syntax error messages in the browser

[GoogleCodeExporter]

To improve the situation for front end developers (mainly working with html, 
css and javascripts) good error messages that won't pass unnoticed is a must.

Digging into server log files is just not an option. Using the tools the 
developer normally uses, like firebug makes a lot of sense.

One way is to simply insert console.error("Error message here") statements in 
generated JS for each error message.

Another option would be to inject the messages into the generated CSS like 
this: 

body { 
 display: none;
}

html:after {
  content: "Error message here\00000aAnother message here";
  white-space: pre;
}

That would probably require some kind of error message listener:
https://code.google.com/p/wro4j/issues/detail?id=118

Clearly, this would only be enabled in debug mode.

Original issue reported on code.google.com by jens.ask...@gmail.com on 27 Nov 2014 at 9:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Could you provide some examples? (resource content, processors being used, 
etc)...

Original comment by alex.obj...@gmail.com on 27 Nov 2014 at 9:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

If a processor produces an error message because of a syntax error in the 
source it's processing, then that message is it's relevant for the developer.

For example, this invalid CSS:
p {{}

Would log something like 

"file.css:123:3 Expected a property or "}": p {{}

in the server log.

If that messages instead was delivered to the browser, it would be much easier 
to spot and correct.

It would be useful for all kinds of processors when running using the filter 
(not maven).

Original comment by jens.ask...@gmail.com on 27 Nov 2014 at 10:08

[GoogleCodeExporter]

A generic error handling mechanism would be an useful feature. But, in the end, 
it is really each processor job to decide how to handle an error. It would be 
easily to implement a small change on a specific processor, rather than 
providing a generic mechanism to handle all kind of exceptions for all 
processors.... 

Original comment by alex.obj...@gmail.com on 27 Nov 2014 at 10:11