2

I'm doing a bit of research for my final year project. It's mostly about creating a more convenient way of dealing with Exceptions thrown in programs. It does this by creating a custom handler for each type of Exception. I was wondering how often are builtin/standard library Exceptions are dealt with in comparison to Exception by you/3rd party software?

Why I'm asking is two fold:

I would like my demonstration as to more realistic. My project has the chance to be more help than just dealing with Exceptions so given the chance, I would rather work on giving the tool far more abilities. Given this, I would like my sample handlers to be bias in the "right" direction.

It will influence how detailed I can make the API to help create more detailed Exceptions and Exception Handlers.

Thanks for taking the time to read this crap.

EDIT:

I'll break it down because I dont think I'm explaining it properly.

The nice little stack trace you get when errors thrown about? I want to try and improve it and see if something before could indicate when it all started to go wrong(for some errors might need a different strategy for others and that's where defining handlers come in). I think I could do this. In order to do this, I need to divide my time accordingly. I want to know whether I should focus on tackling builtin errors or helping people define their handlers for their Exceptions(maybe this second is pointless but I can't know until I ask people). I'll do this by asking people about their experiences.

EDIT2:

I'm a dumbass, I mean errors not exceptions. I need sleep.

Flinsy
  • 101
  • 5
  • In my opinion, this is off-topic because it doesn't have a right answer. The frequency will depend on the library. This would be a better fit for [programmers.stackexchange.com](http://programmers.stackexchange.com) but unfortunately, there doesn't seem to be a large python following there. If you try anyways, I'll post an answer over there. Just post a link in the comments. – aaronasterling Dec 05 '10 at 00:27
  • 1
    I don't understand what use this would be. Why do you believe your approach to be correct? – Ignacio Vazquez-Abrams Dec 05 '10 at 00:28
  • Since Python has so many data-types. functions, and modules built-in, most exception handling will likely be for those they generate. In other words the answer to your question is likely to be highly language dependent. – martineau Dec 05 '10 at 00:36
  • @Ignacio Vazquez-Abrams It's mostly about time allocation. If builtins are more useful to focus on covering more of them as well as the numerous different ways that the Exception can be raised but that will leave less time for building an API for helping building handlers for non standard exceptions as well as getting around to demonstrate the variability that I can handle. If you believe this is BS, please tell me as I would rather not take down a path that's a waste of time. – Flinsy Dec 05 '10 at 00:46
  • I'm confused as to how you think we *don't* have a convenient way of handling exceptions today. (The relative convenience of exception handling usually has a lot more to do with your architecture and programming style than anything related directly to exception mechanics) – Nick Bastin Dec 05 '10 at 01:09
  • A common enough problem here: there's something that he finds inconvenient, and he assumes everyone else finds it inconvenient, so he starts right in with "here's how to fix this big problem" without explaining what he thinks the problem is. (My money's on him using exception handling fundamentally incorrectly.) – Glenn Maynard Dec 05 '10 at 01:17
  • @Nick Bastin In my opinion error handling being handled on your behalf is a nice thing to have. It acts without you having to intervene unless it a fringe case where the solution given back doesn't help you. People may just ignore Exceptions or deal with them in other ways but I'd rather help people eliminate them as much as possible. – Flinsy Dec 05 '10 at 01:20
  • @Glenn Maynard, which is why I'm asking first how do other people deal with them. I use except blocks to figure out what happened, if I can't see what went wrong immediately. – Flinsy Dec 05 '10 at 01:25
  • @Flinsy, though the question is from a different language, you might find the discussion associated with http://stackoverflow.com/questions/2737328/why-should-i-not-wrap-every-block-in-try-catch useful. Exception handling is less about _"figuring out what happened"_ and more about structuring your application to handle errors in a consistent and systematic (possibly layered) manner. This is why automatic processing is generally thought of as a bad idea. Instead, handle exceptions explicitly in precisely the right place in your architecture and let the propagate anywhere else. – D.Shawley Dec 05 '10 at 01:37
  • @D.Shawley , Cheers, helps alot. I don't quite understand though, why is it less preferable to figure out what happened? If I could make it easy for you, would you do it?(only asking to probe the tipping point where it might become more acceptable in terms of programmer time) Isn't programming around the problem more risky in terms of breaking something? It's hard being taught in Uni to catch Errors early in development and eliminate them when others are basically saying what you are. Nice to see other perspectives tho :) – Flinsy Dec 05 '10 at 02:00
  • @Flinsy the difference is between recognizing errors and dealing with them. The best developers anticipate errors and define behavior that minimizes their impact on the application – Rafe Kettler Dec 05 '10 at 02:09
  • @Flinsy: You're confusing exceptions with bugs? – Jochen Ritzel Dec 05 '10 at 02:11
  • @Flinsy: You can't magically handle an exception *for* someone - by definition it is an exceptional case that requires an action on the part of the caller (somewhere in the stack). Unless of course you are writing the development software we all want that intuits what we wanted to do and does it for us. In which case I wish you the best. – Nick Bastin Dec 05 '10 at 02:26
  • @Nick, Ok thanks, no worries. I'm only seeing how far I can actually take this. If I all I can do with this project is deal with builtin errors and help people make more sense of exceptional case. Even if I can't do that, i need to be able to back up those claims to my supervisor so I can change my project slightly. – Flinsy Dec 05 '10 at 02:36
  • @THC4k you could be right, most if not all Exceptions I've dealt with in the past were problems in people's code and as a result I was able to get rid of those errors. I guess it must be one of those Black Sheep of Scotland things. – Flinsy Dec 05 '10 at 02:41
  • @Flinsy: THC4k is on to something here - it seems that you are confusing exceptions with bugs. Exceptions are *not* bugs - you *might* be able to find and resolve exceptions thrown as a *result* of a bug, but exceptions are a type of flow control and a function of a properly operating program. – Nick Bastin Dec 05 '10 at 03:04
  • @Flinsy: You should probably figure out what exceptions are then first. They are a well defined way to leave a function, kind of like a `return` for certain conditions that can't be handled on the spot. Basically thats why so many think "WTF?" when reading this question, it's like wanting to improve `return`. – Jochen Ritzel Dec 05 '10 at 03:07
  • @THC4k Yeah really sorry. I meant errors as in TypeError and NameError and any other xError where x could be a fancy name. Sorry for the confusion. I mean errors as in the nasty bits of code that f up your program. Got mixed up and thought Errors where a subset of Exceptions. In the python Doc NameError is referred to as an Exception in example code so made a stupid assumption. – Flinsy Dec 05 '10 at 03:15
  • @Flinsy: Errors **are** a subset of Exceptions. `NameError` is probably the only error that comes from a programming error most of the time, the others do get used intentionally ... – Jochen Ritzel Dec 05 '10 at 03:43
  • @THC4k This reminds me of the abbott and costello skit "whos on first?" where I know what I mean in my head but I'm crap at explaining it so leave out a couple details that would make all the difference and all hell breaks loose. I'm gonna focus on Errors, the kind of bad stuff that leaves a debris field behind it. We can't fix it at runtime(or it would be an exception :P, i think thats right) so I don't have to touch try except block, right? I think that way I can focus on waiting for the fireworks and examine it after and see how it could have been prevented if at all. I sthat more clear? :) – Flinsy Dec 05 '10 at 03:53
  • I think the OP is really confused here. How about you give us a description of the use case you see for your implementation. Or maybe under what conditions you think exceptions aren't doing what you think they should? You need to think about the problem that you're trying to solve before trying to solve problems. – Falmarri Dec 05 '10 at 05:00

1 Answers1

1

Regardless of what you're trying to do with the answer, I'll answer your specific question:

how often are builtin/standard library Exceptions are dealt with in comparison to Exception by you/3rd party software?

It depends on the domain. Some areas lend themselves to defining specific exceptions (e.g. web programming), and others tend to rely on builtins (e.g. mathematical and scientific computing). The amount of exceptions handled probably leans more towards "standard" exceptions like TypeError or NameError, but harder errors usually aren't contained in the builtins (it's easy to fix an incorrect argument, invalid input, or a typo, which are common causes of exceptions like NameError or TypeError, but it's hard to fix an error that doesn't come from something so simple).

So, IMO, standard exceptions are more prevalent but the ones defined by users, frameworks, etc. are more useful/important (or whatever you want to call it) because they represent more complex and relevant issues.

You can always look at some popular 3rd party Python modules (Google code is a good place to look) and see how many of them define exceptions.

Rafe Kettler
  • 75,757
  • 21
  • 156
  • 151
  • Thanks a mil. I'd like to make it easier for people to deal with exceptions, even if it's a continuous snapshot of the environment to show it going downhill. Or I could help people define default behaviour for errors thrown but allow them to continue the program(potentially eliminating alot of try blocks). This project might be crap but I'm stuck with it so I'm trying to make it good. – Flinsy Dec 05 '10 at 02:20
  • @Flinsy my only suggestion to you with regard to this is you have to make sure you don't mask errors caused by programmers. For example, you shouldn't suppress an error caused by a typo or an invalid argument because, usually, this is the fault of the programmer, and if you suppress that, it's an even bigger problem than before – Rafe Kettler Dec 05 '10 at 02:55