Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualdmatter

Posted 02 August 2013 - 11:35 AM

In many languages (Java in particular - I hate checked exceptions) I feel exception handling is somewhat lackluster.
 
One thing I dislike is having to push a variable declaration up, outside of a try-catch block and assigning null to it, like in HappyCoder's original example (and for value types there might not be a sensible initial value to give it).
 
Perhaps try-catch shouldn't define a scope at all? Initially that seems unworkable if you consider that an exception might cause some vars to not get declared at all. However most catch-blocks don't really handle the error, they just wrap more detail around an exception and re-throw, perhaps with some logging thrown in and occasionally they might also do some cleanup, but either way the stack is about to unwind.

 

Given this, maybe there should be a separate syntax for that use-case: An all-or-nothing try-catch. If it fails you are given a chance to intercept it but ultimately the containing function will exit after that. If it succeeds then any vars declared in the try-block are still kept in-scope for subsequent code to use.

 

I'd be more interested in seeing something like that than an inline try-catch as proposed here.

 

Lacking that you end up either lumping code that didn't really need to be in the try-catch into the try-block. Or, if you only need one variable out, you end up extracting the try-catch into it's own function.


#1dmatter

Posted 02 August 2013 - 11:32 AM

In many languages (Java in particular - I hate checked exceptions) I feel exception handling is somewhat lackluster.
 
One thing I dislike is having to push a variable declaration up, outside of a try-catch block and assigning null to it, like in HappyCoder's original example (and for value types there might not be a sensible initial value to give it).
 
Perhaps try-catch shouldn't define a scope at all? Initially that seems unworkable if you consider that an exception might cause some vars to not get declared at all. However most catch-blocks don't really handle the error, they just wrap more detail around an exception and re-throw, perhaps with some logging thrown in and occasionally they might also do some cleanup, but either way the stack is about to unwind.

 

Given this, maybe there should be a separate syntax for that use-case: An all-or-nothing try-catch. If it fails you are given a chance to intercept it but ultimately the containing function will exit after that. If it succeeds then any vars declared in the try-block are still kept in-scope for subsequent code to use.

 

I'd be more interested in seeing something like that than an inline try-catch as proposed here.


PARTNERS