Typically you'd want to stage each line to a buffer, before checking the address and alignment, and you could eliminate 99.99% of hard faults.
Check also the address you're writing at is blank.
Hard Fault Handlers can return so one could do a try/catch type probing if really adventurous.
.HEX have the ability to be sparse, out-of-order, and describe partial flash-lines.
To process the 0.01%, you could probably just take all of the complete records/lines, and cache the odds, and then come back and try and combine/match up the odd ones, or sort them into a more manageable order/form.
One could also output an error saying the .HEX is invalid or needs to be normalized on a PC, if you really don't like the form as it is presented by the user.
Binary packaging tends to be preferable, the files are 2.5x smaller from the outset, and can be signed/authenticated, or compressed/encrypted.
Yes, built linkers/loaders in the past, tools to generate/consume hex files (Motorola and Intel), DFU files, last FOTA thing I built pulled .HEX from a server via HTTP and wrote content to flash.
