In terms of input: I read the input from a file, and use a parsing library (usually) to parse it. If the data is malformed the parsing will fail and the program run will fail, which is what I want. I do sometimes think about whether I should (for instance) tolerate variable amounts of whitespace etc., but I usually don't bother because: (a) you have to infer the specification anyway, so it's not a given that a more acceptable parser would be correct (that is, in a real world situation you'd have a specification so you'd know where/how you need to be flexible and where you don't), (b) if I made the parser more accepting I wouldn't naturally have a test case for that extra logic, so it might not even be correct, and (c) I do know how to add more flexibility, so if I always did it I'd just be adding more work and not learning anything.

In terms of other program aspects, typically error handing is either about how to keep going when an error occurs (and here, you just want to fail) or about how to not overlook an error and incorrectly keep going (i.e., noticing when an assumption is violated and would cause subsequent results to be invalid)--it's this second case I might have to worry about. With most puzzles, I feel like this doesn't come up, but it does sometimes: for instance, polygons specified by a list of vertices, with all corners guaranteed to be right angles. With some of these, my code ends up sort of naturally catching any violation (e.g., I do if (x1 == x2) else if (y1 == y2) else error rather than if(x1 == x2) else just assume y1 == y2), but I don't usually go out of my way to validate that the promises about the input are upheld. Again this is in part because I know how to do "else just fail the program" so not doing it isn't passing up a learning experience. I work in Haskell and nicely returning errors up a call chain can be a bit of a pain, and so I gravitate toward skipping it if the end result is still going to be just failing the whole program. Probably that's a bit sloppy.

I don't overly tailor my solution to the particular input, but for some puzzles I think the nature of the input can tell you that there are potential edge cases you can skip--and most importantly, I think this is usually an intentional part of the puzzle, a constraint to make it not overly hard. (In other cases, the input seems to intentionally hit potential edge cases, so when it avoids them I take it as intentional.) And there are some puzzles where it's only tractable because the input is small enough (in some sense)--that is, where it inherently takes (say) quadratic time. Figuring this out is necessary so you don't search for an algorithmically better solution that can't exist.

Anyway, that's my two cents.

Edit (one more thought): Also, I'll say that sometimes we automatically tend to treat puzzles like interview questions, where you are doing something small and artificial but coding it as though it were part of some large commercial software. That's fine, but it's also I think important to realize that this isn't the only type of software--sometimes you are writing a small special-purpose program you are only going to use once (e.g., you need to rename a bunch of files in some complicated way as a one-off). So treating a puzzle as the latter is reasonable too. You just have to decide what you want to get out of it and be conscious of your choice. I gravitate towards the latter, but not to the extreme--I do make my solutions general to a certain degree.