in reply to Error handling

It really depends on many things. If, for example, the result is used only for an application that provides a progress estimate to you, almost no error handling is needed at all. If a wrong ID can spoil the data and destroy weeks of measuring in a special lab, you have to handle every possible problem.

Check for errors as soon as you can detect them - it also helps in fixing the data (you do not have to reverse-engineer the original problem from a wrong output).

لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

Replies are listed 'Best First'.
Re^2: Error handling
by Ari (Acolyte) on Sep 17, 2012 at 21:45 UTC

    That makes sense, thanks. In this instance, realistically the only actual chance of error is the user inputting something wrongly in step 1. By the time it's gone through steps 2-4 (which do have checks in place, and I'm working on verifying the input during step 1) it's just following a long-established business process (which has been working flawlessly for, oh, ten years or so).

    Followup question: is there such a thing as too much error handling?

      ... is there such a thing as too much error handling?

      Yes. Does it make the code more difficult to maintain? Is it too expensive in terms of resources?

      I spend most of my error handling budget at the edges of the application, where data can come in or where it's easy to misuse an API. I spend a lot of time making sure it's difficult, if not impossible, to misuse an API.