[BUG] No warning for when folder doesn't exist

[JacobHaig]

Describe the bug
I was following the quickstart guide example on https://docs.rs/plotters/0.3.0/plotters/ and I noticed that the image was not generating when the folder doesn't exist. There is no warning or error. It seems like it is intended that if the folder doesn't exist, the folder would be created.

To Reproduce
let root = BitMapBackend::new("folder-that-doesnt-exist/0.png", (640, 480)).into_drawing_area();
needs to be changed to

let root = BitMapBackend::new("folder-that-exists/0.png", (640, 480)).into_drawing_area();
or
let root = BitMapBackend::new("0.png", (640, 480)).into_drawing_area();

Version Information
plotters = "0.3" from Crates.io

[38]

Hi there, thanks for trying Plotters!

This is actually a know behavior, but you are right, it's confusing. Originally, it panic during drop - bitmap only encode the image file when the bitmap backend is being dropped - But this causing troubles and we have a fix for this #99

Note the code has been moved to

https://github.com/plotters-rs/plotters-bitmap/blob/3891badaf5916cd1ffbbd55dd21239e671a4b0b8/src/bitmap.rs#L1002

But I realized current behavior is very confusing, since it silently drop any IO error - But in fact the rust std did the same thing. But I believe the solution would when the bitmap backend is created we check if the file is writable first.

However, this introduce a breaking change, since current API doesn't returns a result.

So I guess we may want to add a new API let's say create to plotters-bitmap backend which check if the file writable and return error when it's impossible to write the target file. And finally we can deprecate what we currently have, at least we can mark the BitMapBackend::new deprecated once we provided a new method.

Let me know if you have any ideas!

Thanks,
Hao

[ijackson]

Hi. Thanks for this library. I just encountered this situation.

I found the behaviour quite disturbing and not what I expected from a Rust program: it's normally quite difficult to accidentally write a Rust program which ignores file write errors. Having read the issue et . I see that it's not entirely trivial to fix. IMO the root cause is the use of drop to do serious amounts of work, including fallible work. That doesn't work very well, as we see.

For now, I think a short term answer is to have everyone who uses BitMapBackend::new() also call .present()?. I'll submit MRs shortly to do that in the examples, and add a note to the documentation.

That's still not perfect because it still makes it quite easy to accidentally write an unreliable program - all you have to do is forget to call .present()?. Generally in the Rust community we try to help the programmer avoid mistakes and help them write a correct program. There are various new API schemes that could be used, I think:

1. Have the file-writing BitMapBackend not contain the output filename. Instead, the user would have to write something like root.write("filename.png")?. Missing this out would result in a program that didn't do anything - and it would be pretty obvious to the programmer that they had to supply the output filename :-). (As a consequence, the nontrivial Drop impl would no longer be needed.)

2. Provide a BitMapBackend::with() function that would take a closure |root| .... This with API would return Result. The user would never have an owned backend so wouldn't be able to forget to present it and just drop it by mistake. This is probably not much fun with the existing API since there are several constructors and they would all need to be replicated. But maybe a builder pattern would help.

3. In any case introduction of a builder pattern would solve some of the problems with API evolution. If new changed to return a BitMapBackendBuilder, and no longer took a filename, users who upgrade to the new API would have an obvious fix and the obvious fix would be right.

Some of these ideas might work well together, and some could perhaps be added to the existing API without a major version bump.

So I guess we may want to add a new API let's say create to plotters-bitmap backend which check if the file writable and return error when it's impossible to write the target file

I think this is a bad plan. There are lots of things that can go wrong that can't be reliably detected in advance. Every IO operation is potentially fallible. So this proposed API would still be unreliable; it would just go wrong more rarely but more confusingly.

Thaniks for your attention.