Warp wrote:
>   Of course in practice people don't usually use exceptions for expected
> errors, only for severe ones. 

I don't think it's "expected vs severe", at least not in code where people 
have thought about it. It's more "errors you're likely going to want to 
handle right where they happen (such as not being able to open the file 
you're trying toopen)" vs "errors you likely have a more global catch for 
(such as divide by zero or out of disk space)".

The advantage of the exception mechanism is you can catch a bunch of 
exceptions anywhere in a bunch of called routines with one catch. If the 
type of error is one that 95% of the time I want to handle the error right 
where it happens (like "OK, couldn't open it, so I'll create it" or "I'll 
prompt the user for a different name" or something) then it doesn't make 
sense to code it as an exception.

And I think that's where Java's checked exceptions concept fails: They 
explicitly turn the things you want to test for into exceptions, then 
require you to test for them anyway with a much more tedious and distracting 
syntax.


As for exiting a thread by forcing it to throw an exception, that makes 
perfect sense from an implementation point of view.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message