Are there any technical details available concerning how notifications determine whether they should be fired?

The on started/completed/error checkboxes make sense intuitively, but how does a job or task know that there was an error?

Most of my tasks are "execute" tasks which run windowless applications (typically to poll a database server and do something with the data). There is usually a lot of error handling built into these apps, and they run with the .NET runtime. Exceptions are usually handled and logged in a file.

Now I realize that if I handle an exception (and log it to a file), the exception is not propagating up the .NET runtime so there's no way for VC to realize that there was an error.

So I suppose what I'm asking is, what triggers the "on error" status for a task? A .net exception? A nonzero exit code? Any other technical or OS details I should know? Ultimately we'd like to be able to change our apps that are controlled by VC so that VC can actually respond if there is an error.

Right now I suppose the only time the on error would be triggered would be if the app crashed halfway through a run or if there was a bizarre unhandled exception.

When looking at the Execute Task we consider any other Exit code than zero a failure. We also capture all other errors that could occur and mark with the exit code 77777. If any Task fails within a Job the Job has considered failing.

---

Sometimes sloppy .NET programming leads to an annoying runtime popup that says "there was an unhandled exception in process whatever...."

If a task controlled by a VC job did this, since the process would not be running in an interactive session, I am wondering what would happen? I assume that would cause the task to be considered in an error state?

It depends on OS. But if this should happen on a WinForms application that runs from a service with interactive mode on it will show the error in the Interactive services dialog.

If you don't have interactive mode on the VisualCron service it will be a hidden process waiting for input.

If you suspect that you have such an application (that creates these kind of errors) you should create a timeout on the Task.

---

These don't run from a service unless you mean the VC service itself. They are just "execute" tasks. They are windowless applications, though... so basically like console applications without an MS-DOS window popping up. They run in the background, but a .NET runtime error usually pops up a modal dialog courtesy of the runtime.

A timeout might make sense, but I was hoping VC would trap this sort of exception and consider it an error.

The OS is Windows 2003 R2 server.

I was thinking about the VC service itself. If you have a sample application we can test it.

---

I think that is a Windows setting. Somewhere in the registry, to control if that popup should come up or not.

---