This project has moved. For the latest updates, please go here.
1

Closed

if an error occurs process should return non-zero

description

Normally if a process has no errors it returns zero but returns non-zero (some error code) if an error occurs.

On my build server sqlinstaller is returning zero even if there is a sql error so the build server thinks that the task succeeded.

Is is possible to detect the sql error and stop processing and return an error code so the build server will detect the error?
Closed Apr 4, 2013 at 1:57 PM by bschloz

comments

bschloz wrote Apr 3, 2013 at 1:49 PM

The original behavior was to return non-zero if any error occurs but that caused problems when running as a post-build event in Visual Studio and/or running as a task in Team Build. A quick patch was made to always return zero and rely on the output messages (which VS then uses to interpret whether or not an error has occurred). As you point out, this is not ideal when running the command as part of a larger process (e.g. outside of VS or TFS) which relies on the return code from the process to make a decision.

Now, a comprehensive fix would be as follows. First, any error which occurs that is non-content related (e.g. malformed connection string, cannot connect to server, etc) should always return non-zero (possibly have individual error code indicating exactly the issue). Second, any content related errors should by default not affect the process return code. In other words, the process successfully ran and executed all of the user's SQL scripts but there were one or more errors contained within the scripts. And finally, optionally (command line option) alter this default behavior and also return non-zero when any content-related error occurs.

ormico wrote Apr 3, 2013 at 6:38 PM

Yeah, that would work. I would be fine with setting a command line or config file option to have it return the error code for a sql error.

I also agree. An Application error should always return an error so the user knows it isn't being called correctly.

wrote Apr 4, 2013 at 1:57 PM

Resolved with changeset 85800.

wrote May 16, 2013 at 8:05 AM