Improve error message of print_active_bridges

[blegat]

What do you think if the fix for this ?

julia> model = Model(SDPLR.Optimizer)

julia> print_active_bridges(model)
ERROR: MathOptInterface.GetAttributeNotAllowed{MathOptInterface.ObjectiveFunctionType}: Getting attribute MathOptInterface.ObjectiveFunctionType() cannot be performed: SDPLR.Optimizer does not support getting the attribute MathOptInterface.ObjectiveFunctionType(). You may want to use a `CachingOptimizer` in `AUTOMATIC` mode or you may need to call `reset_optimizer` before doing this operation if the `CachingOptimizer` is in `MANUAL` mode.
Stacktrace:
  [1] get_fallback(model::SDPLR.Optimizer, attr::MathOptInterface.ObjectiveFunctionType)
    @ MathOptInterface ~/.julia/packages/MathOptInterface/JdLrc/src/attributes.jl:409
  [2] get(::SDPLR.Optimizer, ::MathOptInterface.ObjectiveFunctionType)
    @ MathOptInterface ~/.julia/packages/MathOptInterface/JdLrc/src/attributes.jl:390
  [3] get
    @ ~/.julia/packages/MathOptInterface/JdLrc/src/Bridges/bridge_optimizer.jl:1177 [inlined]
  [4] print_active_bridges(io::Base.TTY, b::MathOptInterface.Bridges.LazyBridgeOptimizer{SDPLR.Optimizer})
    @ MathOptInterface.Bridges ~/.julia/packages/MathOptInterface/JdLrc/src/Bridges/debug.jl:544
  [5] (::JuMP.var"#6#7"{Base.TTY})(m::MathOptInterface.Bridges.LazyBridgeOptimizer{SDPLR.Optimizer})
    @ JuMP ~/.julia/dev/JuMP/src/JuMP.jl:832
  [6] _moi_call_bridge_function(::Function, ::MathOptInterface.Bridges.LazyBridgeOptimizer{SDPLR.Optimizer})
    @ JuMP ~/.julia/dev/JuMP/src/JuMP.jl:691
  [7] _moi_call_bridge_function(::Function, ::MathOptInterface.Utilities.CachingOptimizer{…})
    @ JuMP ~/.julia/dev/JuMP/src/JuMP.jl:699
  [8] print_active_bridges(io::Base.TTY, model::Model)
    @ JuMP ~/.julia/dev/JuMP/src/JuMP.jl:831
  [9] print_active_bridges(::Model)
    @ JuMP ~/.julia/dev/JuMP/src/JuMP.jl:888
 [10] top-level scope
    @ REPL[4]:1
Some type information was truncated. Use `show(err)` to see complete types.

It turns out that it can easily be fixed now thanks to jump-dev/JuMP.jl#3979 by using Model(SDPLR.Optimizer, with_cache_type = Float64) but it's very hard to guess from the error message.
I think it could be worth adding a try catch that adds this tip in the error

[odow]

I think the issue is that you've defined MOI.supports_incremental_interface(::Optimizer) = true but not implemented the appropriate getters:
https://github.com/jump-dev/SDPLR.jl/blob/43f64e22680fba67ed178870720c35ba06041d5b/src/MOI_wrapper.jl#L275

So JuMP doesn't know it can't call that until its too late.

[blegat]

Yes but that MOI.supports_incremental_interface(::Optimizer) = true does not mean that the getters are implemented, the docs just says that the model can be built without copy_to:

MathOptInterface.jl/src/MathOptInterface.jl

Lines 210 to 220 in ecdf735

	"""
	supports_incremental_interface(model::ModelLike)
	Return a `Bool` indicating whether `model` supports building incrementally via
	[`add_variable`](@ref) and [`add_constraint`](@ref).
	The main purpose of this function is to determine whether a model can be loaded
	into `model` incrementally or whether it should be cached and copied at once
	instead.
	"""
	supports_incremental_interface(::ModelLike) = false

When I implement a solver interface, when I have the choice between complicating the MOI wrapper by adding caches just to implement the getter and just not implement the getters, I always just not implement them because there is no reason to hard-code a cache inside the MOI wrapper since the user can just use a CachingOptimizer.
When the user just want to query the model that he built which is the case most of the time, having just one cache outer the bridge is enough. And we should only add the cache inner the bridge if the solvers needs it for building, not for the getters, since these getters are rarely used.
In the rare case where the user needs these getters. If he's using the JuMP API, we could help him out with a nice error message explaining that we can just enable this inner cache that we didn't add just for the sake of performance because we didn't expect he would need the getters. When you need this inner cache, it's most probably because you are debugging or inspecting so it's a bit like the -g for enabling debugging, it's off by default for small binaries but you may want to turn it on for debugging ^^

[odow]

This seems like it could be an MOI issue instead?

[blegat]

Yes, we could also simply mention the use of with_cache_type = Float64 in the general error of GetAttributeNotAllowed