This week's book giveaways are in the Jython/Python and Object-Oriented programming forums.
We're giving away four copies each of Machine Learning for Business: Using Amazon SageMaker and Jupyter and Object Design Style Guide and have the authors on-line!
See this thread and this one for details.
Win a copy of Machine Learning for Business: Using Amazon SageMaker and JupyterE this week in the Jython/Python forum
or Object Design Style Guide in the Object-Oriented programming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

Secure by design - how much exception handling is enough?

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


One thing that always makes me wonder is what is a good criteria for selecting the number of exceptions to handle? Authors - your thoughts?
 
Author
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vidya

In general we think it is a good idea to handle exceptions as fast as possible, if possible.

If an API marks that it might throw an exception from a method - then that is a signal that should be taken seriously. What if your API call does not work out well? If network is down, data is broken, or whatever? What could you do to recover and continue? That is what exceptions are about, and why you should handle them as early and fast as possible.

In general, if you do a block with try {} catch (... ) {}, then you must ensure that after you have left the block, then the program is back in a well-defined state - regardless whether it completed the try, or it went into the catch-block. A common mistake is that this is not the case. Fore example, any variable that is defined before the try-catch and that is assigned inside the try also needs to get a sensible value in the catch - a sensible value that the following code knows how to handle.

If you cannot sensibly recover from the exception in the catch-block, you should probably throw a new exception - and it might even be a RuntimeException if it is not sensible for the surrounding code to catch and recover from the condition. But, you should definitely consider if your situation is truly exceptional. It might make more sense to have multiple return values (a union type) to be able to signal "the method returned with the following sensible error signal that you as caller should be aware of and handle in as sensible way".

Chapter 9 contains a deeper discussion on these design considerations.

Yours

  Dan
 
Marshal
Posts: 67533
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How much is the difference between error signals in different languages? If I write Java┬« or another language supporting exceptions, my first thought if anything goes wrong would be, “throw an exception”. What about C which doesn't have a specific exception type?
 
Dan Bergh Johnsson
Author
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Campbell

Well. Indeed there are large differences in error signals. You mentioned C where it is not uncommon for functions to return -1 as an error code.

In chapter 9 we have a discussion about how exceptions can feasibly be replaced by returning "union types" - a type which both include the "normal returns" as one subset within the type, and the "error signals" as another subset within the type. Indeed we have seen lots of misuse of exceptions to signal circumstances that are not exceptional at all. For example, an ATM it might be reasonable to throw exception when it is out of money (if that is exceptional), but not because there is insufficient funds on an account to cover a requested withdrawal (which should be considered a pretty normal scenario).

So, even in languages that do not have exception mechanisms it is possible to design error mechanisms in a way that support security.

Thanks for pointing out this interesting aspect

Yours

  Dan
 
Campbell Ritchie
Marshal
Posts: 67533
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thhank you for the answer; that union sounds really intersting.
 
See ya later boys, I think I'm in love. Oh wait, she's just a tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!