Defaulting a missing dimension is worse than crashing
TLDR: Graceful degradation is good advice for presentation and bad advice for measurement. A missing colour can default. A missing size cannot, because everything downstream will treat your guess as a fact.
The position
width || 200 is not defensive programming. It is fabrication with a fallback's manners.
The reasoning behind it is sound as far as it goes. Do not crash on incomplete input. Render something rather than nothing. Keep the pipeline moving. Every one of those is correct for the things a default is normally used for.
But a dimension is not a preference. It is a claim about the world, and once you invent one, nothing downstream can tell your invention from a measurement.
Why the common advice exists
Defaults earn their reputation on presentation values. A missing font falls back and the text is still readable. A missing colour falls back and the button is still clickable. A missing label falls back and the user still sees a control.
In all of those, the fallback is visibly a fallback. The user can see that the styling is generic, and nothing built on top of the page has recorded "this button is grey" as a fact about the domain.
Measurements do not work like that. There is no visual signature that distinguishes a real 200 from a defaulted 200.
Why it fails for this problem class
We shipped exactly this. A figure arriving from our PDF extractor without a stated size was rendered at 200 by 200 and stretched to fill it.
The import reported success. The artboard count was right. The figure appeared, looked like a figure, and was wrong.
Then it got worse, in the way these always do. The editor's fit to view framed the invented box. The exporter cropped to it. The coordinate round trip measured a user's annotations against it and sent them back to the PDF at coordinates derived from a number nobody had ever measured.
One default, four subsystems downstream, all confidently working from it. A crash would have cost an afternoon. This cost weeks of quietly wrong output that nobody had a reason to question.
The better rule
Split your missing value handling by what the value is for.
Presentation values default. Colours, fonts, spacing, labels, anything whose wrongness the user can see and whose value nothing computes against.
Measurements are resolved or refused. Sizes, coordinates, scales, counts, timestamps, currencies. Try every source of real evidence you have, in order of how much it deserves to be trusted. If they all fail, decline the item and say which one it was.
For our figures that meant three sources before refusing: what the sender stated, the extent of the vector scene beside the raster, and the raster's own intrinsic pixel size, obtained by decoding it. Three chances to find a real number, and no fourth chance to make one up.
Refusing one item out of nine is a visible, actionable result. Mounting nine items where one is silently wrong is not.
What you give up
Robustness on paper. Your import can now fail where it used to succeed, and the success rate in a dashboard goes down. It did not actually go down. It became honest.
A branch you have to write. Resolution chains are longer than || 200. Ours is about fifteen lines including a promise that decodes an image.
Some genuinely harmless defaults. There are cases where any number works because nothing measures against it, and the rule costs you a little ceremony there.
When the common pattern is right
Default freely when the value is decorative, when the consumer is a human eye rather than a calculation, and when the wrongness is visible at a glance.
The test I would apply: if this value turned out to be fabricated, how far would it have travelled before anyone noticed? If the answer is "into an export, a coordinate transform, or another system", it is not a default. It is an input, and inputs are either present or they are missing.