3 ms·

If I am writing code on a project that uses exceptions, I'll use exceptions. If I'm writing my own code, I won't. Exceptions force people using your code to als

If I am writing code on a project that uses exceptions, I'll use exceptions. If I'm writing my own code, I won't. Exceptions force people using your code to also add exception handling into their own applications. It's an intrusive error handling method, and this is one of the reasons I don't use it. Did anybody ever prove scientifically or statistically that exceptions offer clear advantages over return-type error handling? Who decided that exceptions are the path for all programmers to follow?

wvenable 18y ago
Return-type errors force people using your code to also add error checking into their own applications at every call. It's an intrusive error handling method, and this is one of the reasons I don't use it. The clear advantages of exceptions over return-type error handling is: - Exceptions cannot be ignored, error codes are ignored by default. - Exceptions can (and do) contain significantly more information about the error. Stack traces are typical but since exceptions are objects they can contain any amount of extra information. Error codes are typically integers. Sometimes they're just negative integers. - Exceptions free-up the return of functions for useful results. You can call functions as parameters: readAll(OpenFile(GetFileName())). Pretty much any negative practice regarding exceptions apply equally to error codes.
- gruseom 18y ago
  Exceptions cannot be ignored Yet they routinely are, or they are "handled" using a top-level catch that allows for no meaningful action and is little better than throwing the exception to the user. Error codes are typically integers. There's no reason why an error can't be an object. Exceptions free-up the return of functions for useful results. The practice I currently favor is to represent errors as objects of the same type the function returns, objects that represent something meaningful about the error. Of course this isn't always possible and in any case requires good design. There are a lot of advantages to it, though. Pretty much any negative practice regarding exceptions apply equally to error codes. Except the one big problem with exceptions, which is the transfer of control out of context.

wvenable 18y ago

Return-type errors force people using your code to also add error checking into their own applications at every call. It's an intrusive error handling method, and this is one of the reasons I don't use it. The clear advantages of exceptions over return-type error handling is: - Exceptions cannot be ignored, error codes are ignored by default. - Exceptions can (and do) contain significantly more information about the error. Stack traces are typical but since exceptions are objects they can contain any amount of extra information. Error codes are typically integers. Sometimes they're just negative integers. - Exceptions free-up the return of functions for useful results. You can call functions as parameters: readAll(OpenFile(GetFileName())). Pretty much any negative practice regarding exceptions apply equally to error codes.

gruseom 18y ago
Exceptions cannot be ignored Yet they routinely are, or they are "handled" using a top-level catch that allows for no meaningful action and is little better than throwing the exception to the user. Error codes are typically integers. There's no reason why an error can't be an object. Exceptions free-up the return of functions for useful results. The practice I currently favor is to represent errors as objects of the same type the function returns, objects that represent something meaningful about the error. Of course this isn't always possible and in any case requires good design. There are a lot of advantages to it, though. Pretty much any negative practice regarding exceptions apply equally to error codes. Except the one big problem with exceptions, which is the transfer of control out of context.