log.error and runtime

[benouat]

What about changing all the log.error( ... ) to real exceptions that we throw instead ?
In the end, if we ever enter a block where a log.error( .... ) is located, it means that we are really in a bad bad shape...

It will allow us, at least, to activate break on exception, which is a surprisingly great dev feature to me...

What do you think ?

[b-laporte]

Well, in many cases we log errors in the framework where there is no point to break on exception, because the actual error may be an invalid expression for instance (e.g. a pipe that doesn't reference a function) - so a good error message will be better than an exception in this case. This may be different in the application code - but I would leave this choice to the application developer. For instance in an application such as ARD or SECO we may prefer to log an error and push it to a server DB than breaking the application and forcing users to refresh it...

[benouat]

Ok, I get your point, but still disagree.
Even in your example of an invalid expression, it means that what the developer intend to write in the first place is not working, so to me it should throw an exception here !! So he can catch it clearly and correct it.

For example, I don't see any difference between an invalid expression and a wrong variable reference. In the latest, browsers simply throw a Reference Error. Everyone is fine with that.

@b-laporte said

so a good error message will be better than an exception in this case

The good error message can be also embedded in the exception. Nothing prevent us to create and generate our own exception.

I don't know if you know about that, but we could create InvalidPipeExpressionError and throw it. This is something that people usually don't know in JavaScript. You have the same flexibility than any other language. You can extend from Error native Object ! 👍

@Mlaval @PK1A @divdavem @olaf-k what do you think ? (I am asking the question to the developer/user inside you, not the developer/maintainer !

[b-laporte]

Sorry - I realize I was not very clear: actually I fear that in many cases throwing an exception will be of no use to the developer. If we consider the example of the invalid expression, breaking on error would bring the developer in the framework ExpressionHandler class, where she would have difficulties to understand what is the actual expression that fails.

I think it will be more efficient to improve our runtime error messages (e.g. with the expression code and file name) so that the developer quickly finds and fixes the issue..