The cookbook is actually covered by tests, but it only checks the demos which aren't in data diagnostics. It's probably a bad thing to have a test rewritten to pass the code instead of the other way around. This should probably call the same method as the dev tools do to minimize the risk of making a mistake, make sure that the test results are actually relevant, and to save time.

Hey @Benny121221, thanks for pointing this out!

For context I've been removing diagnostic decorators from all plottables as part of #578 and refactoring toward implementing IPlottable which contains methods that allow plottables to validate themselves... so diagnostic mode is a very moving target this week, and I'm not surprised to hear the cookbook generator behaves unexpectedly partially through this refactor.

I'll try to finish refactoring the validation/diagnostic system in the next couple days, then determine how to best merge this in. I'm favoring displaying an error message on the graph instead of throwing an exception, so it's possible this code change isn't required (although I'll merge in the grammatical fixes after I figure that out).

I'm favoring displaying an error message on the graph instead of throwing an exception

The benefit of throwing an exception is that it is very obvious, unit tests will find it and a user will find it without having to actually look at the image (which might be very common if their program generates thousands of images). After all, if the user is expected to look at the image to notice the issue then that issue is going to be noticeable regardless as the plottable will likely be broken. The only new thing is telling them why it's broken.

Personally I think diagnostic mode might benefit from taking an enum like this as a parameter:

enum DiagnosticLevel{
    ignore,
    warning,
    error
}

I think this is the best solution, as throwing errors isn't always the best option, although for some use-cases it is.

Hi @Benny121221, this topic is one I'm actively working on in #578 so I really appreciate your input.

I agree with your main point: an error message on the image isn't always good because images could be generated by tests and not seen by a person, or a person might generate the image and not notice the message.

Personally I think diagnostic mode might benefit from taking an enum like this as a parameter:

enum DiagnosticLevel{
    ignore,
    warning,
    error
}

I also agree with your proposed solution. I haven't implemented this yet, but I plan to in the next few days. I haven't decided on the names yet, but I'm thinking of something like

enum InvalidDataAction{
    ignore,
    debugLog,
    showErrorOnPlot,
    throwException
}

The code underlying this is under active work and a moving target so I'll close this PR, but I invite ideas and criticism about how ScottPlot validates data (and reports errors when it finds them), so feel free to post here or in #578. I'm still working on this functionality though, so it might be a few more days before I have something that's really ready to review.