Your option 1 is the best solution, I think. It's returning all results, including warnings, in a custom object. You're not maintaining state within the object performing your method call, and that means you don't have to worry about retaining and managing your state (e.g. in a threaded scenario, or even calling the method twice in succession and inadvertently losing results).

Don't be afraid of building custom objects for this sort of thing. As well as containing the fields, you can also add methods to this object to tie together this info and report on status e.g. returnResults.hasWarnings())

Your option 1 is the best solution, I think. It's returning all results, including warnings, in a custom object. You're not maintaining state within the object performing your method call, and that means you don't have to worry about retaining and managing your state (e.g. in a threaded scenario, or even calling the method twice in succession and inadvertently losing results).

Don't be afraid of building custom objects for this sort of thing. As well as containing the fields, you can also add methods to this object to tie together this info and report on status e.g. returnResults.hasWarnings()).

You will likely find that more functionality falls into this return object. If I'm doing similar (e.g. in Scala), I often start by returning a tuple (sets of results tied together) and very quickly convert this into a new class with additional functionality)