Define a custom Python exception mirroring the builtin exception format

Question

First of all, here are similar questions that address this problem:
1. Raising exceptions without 'raise' in the traceback?
2. Don't show Python raise-line in the exception stack

No, it is not a duplicate, as the answers don't actually solve the problem.

I don't want to format the actual traceback object. Instead, I want to just format the way it is displayed to the user.

The Code

source.py

class HelloError(Exception):
    pass

def type_hello_here(string):
    if string != 'hello':
        raise HelloError("You must type 'hello', not '{}'".format(string))

script.py

from source import type_hello_here
type_hello_here('hello') # No error here
type_hello_here('booty') # Obviously returns an error because booty != hello

The Bad Exception

Traceback (most recent call last):
  File "D:/python/script.py", line 3, in <module>
    type_hello_here('booty')
  File "D:\python\source.py", line 6, in type_hello_here
    raise HelloError("You must type 'hello', not '{}'".format(string))
source.HelloError: You must type 'hello', not 'booty'

The Desired Exception

Traceback (most recent call last):
  File "D:/python/script.py", line 3, in <module>
    type_hello_here('booty')
HelloError: You must type 'hello', not 'booty'

I want to format it in such a way that the last entry, pointing to the code in the source module is not displayed, as the error does not actually occur there. Also, I want the source in 'source.HelloError' to disappear.

...I really wouldn't worry about this. This is trivial. The only people who should even be seeing the stack trace are developers, and this shouldn't bother them. Give the user a prettier error message, maybe just the actual message from the exception if you must derive it from the exception, but not the whole stack trace. — jpmc26, Mar 24 '16 at 01:21
Absolutely, however I want to write *the perfect program*, and this error is just annoying me and many others. — Nick Pandolfi, Mar 24 '16 at 01:23
There is no perfect code. Only a scale of good and bad code (best measured in "what the hecks" per second, or replace "hecks" with your favorite curse word). Let it go. This will be good practice for you letting small things that don't matter go. 2 months from now, you'll wonder why it ever bothered you to begin with. I promise. Once you do, then you're freed up to go on to the next thing that really does matter. — jpmc26, Mar 24 '16 at 01:26
If you do this, you're just going to *confuse* the people who have to look at this stack trace. For example, they might expect `type_hello_here` to be implemented in C, because this kind of stack trace usually only comes from functions written in C. It stands a pretty good chance of slowing down developer workflow instead of making things easier. — user2357112, Mar 24 '16 at 01:36

idjaw · Accepted Answer · 2016-03-24T01:43:08.930

As mentioned in the comments, there is really no advantage to doing this, and typically when you raise an exception you want to provide other developers with a full stack trace to aid in troubleshooting and provide a better understanding of why and how something failed.

But, for what you are looking to do, something like this could work, but again, you might want to re-think doing this. Utilizing traceback, you can catch the exception you raise and then use print_exc to set your traceback limit to 1:

import traceback

class HelloError(Exception):
    pass

def type_hello_here(string):
    if string != 'hello':
        raise HelloError("You must type 'hello', not '{}'".format(string))

try:
    type_hello_here('booty') # Obviously returns an error because booty != hello
except HelloError as exc:
    traceback.print_exc(limit=1)

Will give output:

Traceback (most recent call last):
  File "stuff.py", line 62, in <module>
    type_hello_here('booty') # Obviously returns an error because booty != hello
HelloError: You must type 'hello', not 'booty'