as_ufl spews a log message even if the exception is caught.

[David Ham]

4ae5bf4 changed the implementation of as_ufl so that the fall-through behaviour doesn't just raise an exception, but also logs an error. This breaks exception handling as the user sees an error message even if I trap that exception.

I would argue that messages should only be logged at error level if they are known fatal. This message should be at debug level so that it does not appear by default. After all, if the exception is caught then it's not actually an error, while if the exception is not caught the user will see this anyway.

[Martin Sandve Alnæs]

Like this?

https://bitbucket.org/fenics-project/ufl/branch/martinal/topic-add-value-error-exception

I'm not sure if there are any errors in ufl that are fatal for the parent process, probably not. But whenever ufl uses as_ufl and it fails, it's surely "fatal" for the task that ufl tries to accomplish. That's rarely a good thing for the parent program anyway.

You can set the logging level of ufl separately of other log systems though, so if you want to consider throwing bad data at ufl and catching exceptions as normal usage, feel free to hide the errors from the users.

[David Ham]

Yes. That patch would do nicely, and I think this is the right approach.

In this particular case, as_ufl is effectively a cast. The corresponding code in Firedrake was attempting to cast a user expression to UFL, and falling back to another route if as_ufl fails. This is IMHO idiomatic Python programming and shouldn't result in UFL logging an error message.

[Martin Sandve Alnæs]

Sure.

I'm not sure if it's valuable that ufl logs error messages at all really, but I won't address that now...