When an error occurs whilst executing a script all the user gets back is the SqlException (or whatever). Whilst it's probably fine if that occurs during a debugging session it's less helpful if it happens whilst just running your app, or in a test environment, or in production, where you may end up having to look at the error after the fact, either in a log file, or using a service such as loggly.
At this point you probably have no idea what exactly the script was, what tables were being written to, what the parameters passed into the script were. All of these are useful diagnostic information and it would be helpful to include them in the log output.
We probably don't want a custom exception type for this, but should just rethrow whatever we catch (as we do at present). The additional information should probably just appear in the log.
When an error occurs whilst executing a script all the user gets back is the SqlException (or whatever). Whilst it's probably fine if that occurs during a debugging session it's less helpful if it happens whilst just running your app, or in a test environment, or in production, where you may end up having to look at the error after the fact, either in a log file, or using a service such as loggly.
At this point you probably have no idea what exactly the script was, what tables were being written to, what the parameters passed into the script were. All of these are useful diagnostic information and it would be helpful to include them in the log output.
We probably don't want a custom exception type for this, but should just rethrow whatever we catch (as we do at present). The additional information should probably just appear in the log.