Updated: Comment #12
Problem/Motivation
Some of our new OO code wants to do things like decode exception messages etc... Like I found earlier doing an IMP patch (_drupal_decode_exception() is being called in the MigrateExecutable class). This is kind of annoying as it's pretty much standalone utility logic.
Proposed resolution
Move methods that make sense into a Drupal\Core\Utility\Error class. format_backtrace, _drupal_get_last_caller, _drupal_render_exception_safe, and _drupal_decode_exception I think make sense. Some of the other methods in there are dependent on watchdog and other things, so maybe leave them. Distilling the useful re-usable things.
Also, remove the _ suffixed functions above, as these are technically not a part of any API that people can rely on.
Remaining tasks
RTBC?
User interface changes
None
API changes
Addition of Drupal\Core\Utility\Error class, but wrapper procedural function will be kept, so BC is kept for error functions. _ (private) functions will be removed.
Comment | File | Size | Author |
---|---|---|---|
#17 | interdiff-2157691-17.txt | 2.4 KB | damiankloip |
#17 | 2157691-17.patch | 28.77 KB | damiankloip |
Comments
Comment #1
jibran80 line chars limit.
Can we add some unit tests as well?
Comment #2
damiankloip CreditAttribution: damiankloip commentedYes, I was think we def need some tests.
Doing this.
Comment #3
chx CreditAttribution: chx commentedSuperb. We could do more in #2160655: Improve error handling of \Drupal class or a followup of it if this happens.
Comment #4
dawehnerWe maybe should at a @deprecated?
As a follow up we should research whether we also can support $connection->query()/$connection->select ... db_query_range though is certainly wrong
What about using String::format ?
Comment #5
damiankloip CreditAttribution: damiankloip commentedOk, here are those changes, as well as some unit tests. I have added tests for the getLastCaller and formatBacktrace methods. However, testing decodeException is a bit awkward - You can't create a new Exception without it being thrown (feature? ;)), you also cannot control the backtrace etc.. so it become messy. Any good suggestions on testing this? I guess we need to arrive at some sort of compromise here.
Comment #7
damiankloip CreditAttribution: damiankloip commentedAh, so the actual raw assertion text it was looking for in ShutdownFunctionsTest is actually wrong. It was (and I guess has been for some time) double escaped as the message is passed through String::checkPlain() in decodeException, then again in _drupal_render_exception_safe().
The changes I have made to Error::renderExceptionSafe is correct, using String::format() now. As the message will actually utilise the output form decodeException now. So changed the shutdown function test assertion text accordingly.
Comment #8
jibranSome minor issues.
Why is it not in compenent like other Utilitiy? Or Why is it in core?
more then 80 chars.
Comment #9
damiankloip CreditAttribution: damiankloip commentedWe have lots of things also in Core\Utility. I added this to Core namespace as stuff like decodeException is pretty specific to Drupal, rather than generalised - IMO. If people disagree though, I can move.
Also, the interdiff contains changes needed from rerolling after #2159459: Rebuild script triggers errors in error handler, fails to rebuild container went in, and made a change to format_backtrace code.
Comment #10
dawehnerJust a note for a possible follow up: Symfony\Component\Debug\Exception\FlattenException has kind of similar functionaliy (ensures that there is no object in the backtrace.
Not really sure whether we should support db_query/db_query_range here, given that most calls should be converted already.
Comment #11
dawehnerBeside that, this is fine for me!
Comment #12
damiankloip CreditAttribution: damiankloip commentedOk, spoke to chx on IRC. Let's just remove the _drupal_decode_exception, _drupal_render_exception_safe, and _drupal_get_last_caller methods here too, and just replace their usages (not too much).
Comment #13
damiankloip CreditAttribution: damiankloip commentedComment #14
chx CreditAttribution: chx commentedI see no problems with nuking private functions at an alpha stage.
Comment #15
dawehner$rtbc = TRUE;
Comment #17
damiankloip CreditAttribution: damiankloip commentedOk, so we can't remove ExceptionController::decodeException (just yet) as it is relying solely on FlattenException, so has some different logic based around this.
Interdiff just to show changes to ExceptionController.
Comment #18
dawehnerLet's git it in in the current working state.
Comment #19
catchLooks great. Committed/pushed to 8.x, thanks!
Comment #20
BerdirLooks like we could have used those methods now in ExceptionController::decodeException() and others there? Follow-up?
It actually did cover that in away, but that implementation is special, as @damiankloip just explained to me.
Comment #21
damiankloip CreditAttribution: damiankloip commentedYeah, we did try to reuse it in ExceptionController, but it has a modified version of decodeException, just for dealing with FlattenException :/
Comment #22
kim.pepperCreated a follow up issue for some missing class names in comments #2170519: Fix missing class name in comments in TestBase