Re: Try/Catch

new topic     » goto parent     » topic index » view thread      » older message » newer message

Hi

jimcbrown said...
Spock said...

As for the tedium of having to check the error code each time, we do this already for calls like open() etc.. I think the error treatment of many calls is context dependent (ie, caller driven) and I personally prefer the freedom of being able to specifically choose when to check any error codes.

One thing try/catch does better is that if you forget to add a check, then the program crashes - so you get fail fast development. Your version doesn't seem to have that (unless you're suggesting that the interpreter crashes when it detects somehow that ERR is set but the caller doesn't check it).

I do not say 'copy this' but maybe you have a look at how other programming languages handle this problem.

Pascal (TurboPascal,Delphi,FPC) use, since the beginning, a compiler switch {I-/+} or {$IOCHECKS OFF/ON}

In the old days if {$I+} is set than the compiler generates a Runtime Error and the is program crashing.
If {$I-} is set than only an ErrorCode is set, that you can check with reading 'IOResult' (it's a function internally and it's reset after reading it).

Nowadays {$I-} behaves the same way than 30 years before ;) 'except' you have a 'try' 'except' block. Than it raises a exception.

And even inside the 'except' block you can use {$I-} and {$I+} to prevent raising an exception in your exception handling (mixing both error check and axception handling).

So this concept gives you the choice to use Error Handling via results or Exception Handling or mix both. And this concept proofed to be working over decades.

Just to say that you are not talking about Exceptions 'OR' Error Codes. You can have both.

Andreas

(btw. there is also {$R-/+} and {$q-/+} for range checking and overflow....)

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu