Host_Error Vs. Sys_Error

[Baker]

In stock Quake, there are a lot of "errors" that end up calling Sys_Error (terminal dialog box) and a few that call Host_Error (console log error).

I haven't looked through the stock Quakeworld code, but in FuhQuake (the Quakeworld client/server to those that don't know) nearly every "world" or "QuakeC" error is a Host_Error.

The consequences of a Sys_Error I am thinking for a remote dedicated server is that it has to be manually restarted, even if in a looping script. But a host_error, the server console is still available.

1. What is the general rule of thumb of situations that should involve Sys_Error with "world" or progs.dat interpreter situations? Are there any?

More or less I am thinking about the best way to code for a stable and reliable and easy to maintain server. One instance of Rook doing this was that he added sv_defaultmap to his customized server engine so the server, if it can't find a map, instead of crashing just loads whatever the sv_default map is.

Yes, this a vague poorly worded topic, but I'm seeking input.

[r00k]

I've used Host_error for most of the pr_ stuff as it also spits out a crap load of things in memory too. This helps with testing mods without having to reload the engine. For example in Kurok, if i press +attack, its crashes to console with an error in W_Attack. If I had a sys error i wouldnt know exactly where that error was.

One comment though in Host_error itself

Code: Select all

   if (cls.state == ca_dedicated)
      Sys_Error ("Host_Error: %s\n",string);   // dedicated servers exit



[Baker]

Code: Select all

   if (cls.state == ca_dedicated)
      Sys_Error ("Host_Error: %s\n",string);   // dedicated servers exit



Good point!

[Spike]

Sys_Error for errors that cannot be recovered from (bad pointers, etc)
Host_Error for errors that can be (qc errors, anything that will go away on a map change).

However, usually it is better for dedicated servers to just quit entirely than to restart. These things are often unobserved and unchecked for weeks/months (or years), and it makes sense to kill them entirely and restart them via a restarter shell script.
Just dropping to the console on a dedicated server is rarely good. You should always have a map loaded.

[mh]

Spike's comment is basically exactly what I was gonna say - use Host_Error where dropping the map is sufficient, use Sys_Error where whatever caused the problem is somehow terminal or can leave things in an incosistent or undefined state that can't be recovered from.

There are other things that shouldn't even be either but are Sys_Error conditions in stock Quake, such as the stuff in SV_StartSound - it's just as easy to clamp to valid ranges.

[metlslime]

However, usually it is better for dedicated servers to just quit entirely than to restart. These things are often unobserved and unchecked for weeks/months (or years), and it makes sense to kill them entirely and restart them via a restarter shell script.
Just dropping to the console on a dedicated server is rarely good. You should always have a map loaded.

This is an interesting point, I wonder if it would make sense to have an engine treat Host_Error as fatal when (dedicated == TRUE), and nonfatal otherwise.

[Team Xlink]

Well is there a way to make a dedicated server restart if it gets an error automatically without external input, where it would be done in the engine itself?

[r00k]

The error though could spin into a relentless loop of loading and crashing! :O

[mh]

Well is there a way to make a dedicated server restart if it gets an error automatically without external input, where it would be done in the engine itself?

I wouldn't do this as you don't know that the event which caused the error has been cleared. If it's memory corruption of the program's heap (which would be managed by the OS, not the program) for example, the only way to really ensure that it's been cleared is to fully unload and reload the program.