remove "error", "exception", "warning" from what we report

[syclik]

Messages from exceptions should not have the terms:

• [ ] error
• [ ] exception
• [ ] warning

[syclik]

"error" can be included for initialization errors, etc. that really are errors.

[syclik]

Places where I've found potentially problematic messages:

• src/stan/optimization/bfgs.hpp
  • ModelAdaptor - constructor
  • operator() (how does this even work? it doesn't look syntactically correct)
• src/stan/mcmc/hmc/hamiltonians/base_hamiltonian.hpp
  • _write_error_msg()
• src/stan/io/json_parser.hpp
  • json_exception()
• src/stan/common/init_adapt.hpp
  • init_adapt()
• src/stan/common/command.hpp
  • command(): will also need to update RStan and PyStan accordingly
• src/stan/mcmc/chains.hpp
  • covariance()
  • correlation()
• src/stan/math/error_handling/dom_err.hpp
• src/stan/math/error_handling/dom_err_vec.hpp
• src/stan/gm/grammars/term_grammar_def.hpp
  • struct set_fun_type_named
  • struct division_expr
  • struct set_var_type
• src/stan/gm/grammars/statement_grammar_def.hpp
  • struct validate_sample
• src/stan/common/write_error_msg.hpp
  • write_error_message()
• src/stan/io/stan_csv_reader.hpp
  • parse()
• src/stan/math/matrix/inverse_spd.hpp
  • inverse_spd()
• src/stan/gm/grammars/functions_grammar_def.hpp
  • struct add_function_signature
• src/stan/gm/generator.hpp
  • generate_write_loop() [edit: 8/5 -- removed checkboxes]

[bob-carpenter]

What's the context for all of these changes. Is this just not to freak people about for warnings that cause rejections?

Is the plan to have whatever's doing the catching and handling indicate severity of the "problem" or "issue"?

[syclik]

The context for changes:

• consistency. It was up to the implementer to generate the messages and sometimes "error" was used and sometimes not. I think we want to avoid the word "error" in the messages and wrap the severity somehow.
• We don't want to freak out users unintentionally.

Yes, I believe that we should indicate severity from the outside. I'm not sure how we would accomplish that, but that should be the goal. I don't think the underlying function calls should just deal with identifying an error and taking action.

I just swept threw all the functions and we've reduced the word "error" from our messages quite a bit. Here are the places where they still exist (I might have missed a few):

• [ ] src/stan/optimization/bfgs.hpp
• [ ] src/stan/math/matrix/min.hpp
• [ ] src/stan/math/matrix/max.hpp
• [ ] src/stan/math/matrix/inverse_spd.hpp
• [ ] src/stan/math/matrix/assign.hpp
• [ ] src/stan/io/stan_csv_reader.hpp
• [ ] src/stan/io/json/json_parser.hpp
• [ ] src/stan/io/json/json_data_handler.hpp
• [ ] src/stan/common/do_bfgs_optimize.hpp
• [ ] src/stan/common/command.hpp

The action is to clean up these files and reword the messages, calling existing error-checking functions where appropriate.

[syclik]

This depends on #1751 and is related to #512.