Exceptions

[LB]

MiiNiPaa wrote:

Nope there is a OS (Earth) running several large business programms (Cities). The hotel is one of many subsystems of said program. And it should make sure that it will continue working because cost of hour of idling is larger than my yearly payment.

I thought the Earth was the basement with all the servers (cities) in it?

MiiNiPaa wrote:

But how should program handle sudden HDD failure in a middle of writing several days works result? And should it?

It shouldn't, because it shouldn't be saving several days of work - it should save more often than that and not overwrite existing data. That way a worst-case non-recoverable failure is not a setback of several days, but of only an hour or less, depending on the size of the data being saved and the optimizations to minimize that.

[MiiNiPaa]

I thought the Earth was the basement with all the servers (cities) in it?

It will be universe.

it should save more often than that and not overwrite existing data

That was a real example. System in question in in the middle of forest and you have to drive to in once a week and dump data on portable storage using COM cable. No GSM coverage, no possibility to connect it to the network, no budget to place storage device and power it, no way to change hardware (to make it at least suppot USB)

[LB]

MiiNiPaa wrote:

> I thought the Earth was the basement with all the servers (cities) in it?
It will be universe.

I thought the universe was the company that owned the basement with all the servers in it?

MiiNiPaa wrote:

That was a real example. System in question in in the middle of forest and you have to drive to in once a week and dump data on portable storage using COM cable. No GSM coverage, no possibility to connect it to the network, no budget to place storage device and power it, no way to change hardware (to make it at least suppot USB)

Wouldn't you be copying the already-saved data? Where does it store it in the first place?

[MiiNiPaa]

I thought the universe was the company that owned the basement with all the servers in it?

It will be some highe dimensional world...

Where does it store it in the first place?

RAM. It does not any actual storage aside from ROM where program is written. System should be restarted regulary to do hardware self-test and reset some data which cannot be accessed programmatically. COM-IDE HDD rack was old as hell and could disconnect because of slight tilt.
We actually rip HDD out of it after successful writing and connect it to the laptop to backup data if said HDD decides to die before we return to the institute. And if it dies before backup we should connect to the system and prevent it from rebooting in 1-minute grace period after dumping data; and quickly search for new one. In the middle of forest. We increased it to 5 minutes when we get permission to update program, so we had not to be in a rush.

[DeXecipher]

they seem like another novelty feature, not totally necessary. ANy high performance app doesn't use throw or exceptions especially in the game iindustry. Assert() with logging is a better alternative imo. I can see how exceptions can be useful in business type apps where you deal with users typing invalid sh!t.

[Cubbi]

How many more decades need to pass for a core language feature to stop being considered 'novelty'?

[rapidcoder]

ANy high performance app doesn't use throw or exceptions especially in the game iindustry

LOL. Exceptions, at least how implemented in Java, don't incur any runtime overhead when they are not thrown, contrary to Assert with logging.

I can see how exceptions can be useful in business type apps where you deal with users typing invalid sh!t.

Yeah, and then we see games that hang or crash if a user has wrong version of DirectX, unsupported hardware or his game DVD is scratched and the game can't read the textures. Instead of displaying nice error message with instructions how to fix that. ;)

Exceptions are usually used for something more exceptional than dealing with users typing invalid sh!t. You don't use exceptions for something very probable like that.

[Zaita]

@rapidcoder Actually Exceptions (the try block) does cause quite a significant amount of overhead. One of my population models is 100% faster when I disable exceptions. This brings runtime down from 2 seconds to 1 second. Which in an MCMC saves 11 days run time...

@DeXecipher is correct that they are not preferred for high performance computing because of the overhead.

[rapidcoder]

That's interesting, but I said *in Java* exceptions do not incur any overhead. There is not an even single CPU opcode generated for the try statement. Might be that your compiler is not very smart at implementing them (perhaps it is using the setjmp/longjmp method, which is know to be slow).

[MiiNiPaa]

@DeXecipher is correct that they are not preferred for high performance computing because of the overhead.

But they are preferred in cases where safety, readability and extensibility are preferred over speed.
While local gotos can make your code unreadable mess, setjmp/longjmp used to traverse stack in C (usually to handle errors) will make debugging mistake in error handling into nightmare.

[rapidcoder]

Ok, so I was right, some C++ compilers use quite an expensive method of enabling exceptions:
http://preshing.com/20110807/the-cost-of-enabling-exception-handling

They seem to be installing exception handlers on each entry into a try-catch block or any method that can potentially throw exceptions (which if you enable them globally - is just any method that cannot be statically analyzed it doesn't throw = most of the nontrivial methods calling to other units).

JVM does not need to do it, because it fully controls the environment: it knows the addresses of exception handlers at class-loading time and also knows the stack-frame structure of every loaded method. So, whenever you throw an exception, it can locate all the exception handlers by examining current value of the program counter and it is easy to unwind the stack, because it knows where the return pointers are. So all the cost is offshored to static analysis at classloading / runtime compilation and then to throwing the exception. If you don't throw, there is no cost.

C++ compiler obviously cannot use this technique, because it isn't guaranteed to see all of the code - it can see only a single unit of compilation. Therefore it doesn't know how to unwind the stack of the callers from different units of compilation. Therefore, it can't be precomputed and it has to register/unregister exception handlers dynamically, on method calls, wasting a few CPU cycles per each method.

BTW: additionally Java offers a nice way of throwing very lightweight exceptions that do not collect the stack-trace. They can be used to jump out of deeply recursive calls, something like a non-local but fast goto.

BTW2: Exceptions are also significantly faster than manual checking for nulls everytime, whenever you don't expect nulls to be frequent.

If probablity of null is low, this code is slower on average:

if (someObject != null)
  someObject.doSomething();
else
  handleError();

than this code:

try {
  someObject.doSomething();
} 
catch (NullPointerException e) {
  handleError();
}

The latter actually does not use any special instructions for nullchecking, the exception gets triggered by hardware interrupt.

[Cubbi]

Zaita wrote:

Exceptions (the try block) does cause quite a significant amount of overhead. One of my population models is 100% faster when I disable exceptions

Have you filed a bug report with your compiler vendor? Depending on the exception handling implementation they use, there should be either exactly zero, or very low overhead.

[rapidcoder]

I don't think exactly zero is possible in case of a method that links to another unit of compilation (how would the callee know the address to jump to on exception?) - the exception handler has to be installed on entering the try block and deinstalled on leaving, which may take a few additional CPU cycles. But 100% overhead is probably too much.

[Cubbi]

...where by "very low" I mean "no more than what the equivalent C-style return code error checking would introduce", which is the typical benchmark for the lazy vendors.

[cire]

Hello Mr. Table!

VC++ uses a form of exception handling by default that is a little more costly than one might expect as it enables catching faults and stuff, but it is possible to disable that. I would expect gcc uses a zero cost approach by default.

http://stackoverflow.com/questions/691168/how-much-footprint-does-c-exception-handling-add
seems to imply that it does.

[LB]

@rapidcoder: I would like to know how asserting that a condition is true (and logging otherwise) is more costly than using an if-statement to check if it is false (which would then throw an exception).

[rapidcoder]

@LB it is costly, because you have to do it many more times than when using exeptions.


Compare:

int upperLevel() 
{
   if (doSomethingThatMightFail() != 0)   // you may use Assert as well
   {
      crap();
      return -1;
   } 

   if (doSomethingOtherThatMightFail() != 0)
   {
      crap();
      return -1;
   } 

   ...
}

int upperLevel() 
{
   try 
   {
     doSomethingThatMightFail();
     doSomethingOtherThatMightFail();
   }
   catch (Exception e) 
   {
      crap();  
      return -1;
   } 
}

[LB]

With assertions, your first example should be:

int upperLevel()
{
    doSomethingThatMightFail();
    doSomethingOtherThatMightFail();
}

void doSomethingThatMightFail()
{
    assert(status, "failed");
}

void doSomethingOtherThatMightFail()
{
    assert(status, "failed");
}

With exceptions only the function definitions change:

void doSomethingThatMightFail()
{
    if(!status) throw blah;
}

void doSomethingOtherThatMightFail()
{
    if(!status) throw blah;
}

In both cases (assertions, exceptions) only two checks are made.

[Bourgond Aries]

L B wrote:

assert(status, "failed");

According to http://en.cppreference.com/w/cpp/error/assert assert takes only 1 argument.

[MiiNiPaa]

He probably meant assert(status && "failed");. That is how you do it actually.